From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6216.txt | 3755 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 3755 insertions(+) create mode 100644 doc/rfc/rfc6216.txt (limited to 'doc/rfc/rfc6216.txt') diff --git a/doc/rfc/rfc6216.txt b/doc/rfc/rfc6216.txt new file mode 100644 index 0000000..4ca6e1e --- /dev/null +++ b/doc/rfc/rfc6216.txt @@ -0,0 +1,3755 @@ + + + + + + +Internet Engineering Task Force (IETF) C. Jennings +Request for Comments: 6216 Cisco Systems +Category: Informational K. Ono +ISSN: 2070-1721 Columbia University + R. Sparks + B. Hibbard, Ed. + Tekelec + April 2011 + + + Example Call Flows Using Session Initiation Protocol (SIP) + Security Mechanisms + +Abstract + + This document shows example call flows demonstrating the use of + Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail + Extensions (S/MIME) in Session Initiation Protocol (SIP). It also + provides information that helps implementers build interoperable SIP + software. To help facilitate interoperability testing, it includes + certificates used in the example call flows and processes to create + certificates for testing. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6216. + + + + + + + + + + + + + +Jennings, et al. Informational [Page 1] + +RFC 6216 SIP Secure Call Flows April 2011 + + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Certificates . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 4 + 2.2. Host Certificates . . . . . . . . . . . . . . . . . . . . 8 + 2.3. User Certificates . . . . . . . . . . . . . . . . . . . . 10 + 3. Call Flow with Message Over TLS . . . . . . . . . . . . . . . 12 + 3.1. TLS with Server Authentication . . . . . . . . . . . . . . 12 + 3.2. MESSAGE Transaction Over TLS . . . . . . . . . . . . . . . 13 + 4. Call Flow with S/MIME-Secured Message . . . . . . . . . . . . 15 + 4.1. MESSAGE Request with Signed Body . . . . . . . . . . . . . 15 + 4.2. MESSAGE Request with Encrypted Body . . . . . . . . . . . 20 + 4.3. MESSAGE Request with Encrypted and Signed Body . . . . . . 22 + 5. Observed Interoperability Issues . . . . . . . . . . . . . . . 27 + 6. Additional Test Scenarios . . . . . . . . . . . . . . . . . . 29 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 32 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 34 + Appendix A. Making Test Certificates . . . . . . . . . . . . . . 35 + A.1. makeCA script . . . . . . . . . . . . . . . . . . . . . . 36 + A.2. makeCert script . . . . . . . . . . . . . . . . . . . . . 40 + Appendix B. Certificates for Testing . . . . . . . . . . . . . . 42 + B.1. Certificates Using EKU . . . . . . . . . . . . . . . . . . 42 + B.2. Certificates NOT Using EKU . . . . . . . . . . . . . . . . 51 + B.3. Certificate Chaining with a Non-Root CA . . . . . . . . . 58 + Appendix C. Message Dumps . . . . . . . . . . . . . . . . . . . . 64 + + + + + + + +Jennings, et al. Informational [Page 2] + +RFC 6216 SIP Secure Call Flows April 2011 + + +1. Introduction + + This document is informational and is not normative on any aspect of + SIP. + + SIP with TLS ([RFC5246]) implementations are becoming very common. + Several implementations of the S/MIME ([RFC5751]) portion of SIP + ([RFC3261]) are also becoming available. After several + interoperability events, it is clear that it is difficult to write + these systems without any test vectors or examples of "known good" + messages to test against. Furthermore, testing at the events is + often hindered due to the lack of a commonly trusted certification + authority to sign the certificates used in the events. This document + addresses both of these issues by providing messages that give + detailed examples that implementers can use for comparison and that + can also be used for testing. In addition, this document provides a + common certificate and private key that can be used to set up a mock + Certification Authority (CA) that can be used during the SIP + interoperability events. Certificate requests from the users will be + signed by the private key of the mock CA. The document also provides + some hints and clarifications for implementers. + + A simple SIP call flow using SIPS URIs and TLS is shown in Section 3. + The certificates for the hosts used are shown in Section 2.2, and the + CA certificates used to sign these are shown in Section 2.1. + + The text from Section 4.1 through Section 4.3 shows some simple SIP + call flows using S/MIME to sign and encrypt the body of the message. + The user certificates used in these examples are shown in + Section 2.3. These host certificates are signed with the same mock + CA private key. + + Section 5 presents a partial list of items that implementers should + consider in order to implement systems that will interoperate. + + Scripts and instructions to make certificates that can be used for + interoperability testing are presented in Appendix A, along with + methods for converting these to various formats. The certificates + used while creating the examples and test messages in this document + are made available in Appendix B. + + Binary copies of various messages in this document that can be used + for testing appear in Appendix C. + + + + + + + + +Jennings, et al. Informational [Page 3] + +RFC 6216 SIP Secure Call Flows April 2011 + + +2. Certificates + +2.1. CA Certificates + + The certificate used by the CA to sign the other certificates is + shown below. This is an X.509v3 ([X.509]) certificate. Note that + the X.509v3 Basic Constraints in the certificate allows it to be used + as a CA, certification authority. This certificate is not used + directly in the TLS call flow; it is used only to verify user and + host certificates. + + Version: 3 (0x2) + Serial Number: + 96:a3:84:17:4e:ef:8a:4c + Signature Algorithm: sha1WithRSAEncryption + Issuer: C=US, ST=California, L=San Jose, O=sipit, + OU=Sipit Test Certificate Authority + Validity + Not Before: Jan 27 18:36:05 2011 GMT + Not After : Jan 3 18:36:05 2111 GMT + Subject: C=US, ST=California, L=San Jose, O=sipit, + OU=Sipit Test Certificate Authority + Subject Public Key Info: + Public Key Algorithm: rsaEncryption + RSA Public Key: (2048 bit) + Modulus (2048 bit): + 00:ab:1f:91:61:f1:1c:c5:cd:a6:7b:16:9b:b7:14: + 79:e4:30:9e:98:d0:ec:07:b7:bd:77:d7:d1:f5:5b: + 2c:e2:ee:e6:b1:b0:f0:85:fa:a5:bc:cb:cc:cf:69: + 2c:4f:fc:50:ef:9d:31:2b:c0:59:ea:fb:64:6f:1f: + 55:a7:3d:fd:70:d2:56:db:14:99:17:92:70:ac:26: + f8:34:41:70:d9:c0:03:91:6a:ba:d1:11:8f:ac:12: + 31:de:b9:19:70:8d:5d:a7:7d:8b:19:cc:40:3f:ae: + ff:de:1f:db:94:b3:46:77:6c:ae:ae:ff:3e:d6:84: + 5b:c2:de:0b:26:65:d0:91:c7:70:4b:c7:0a:4a:bf: + c7:97:04:dd:ba:58:47:cb:e0:2b:23:76:87:65:c5: + 55:34:10:ab:27:1f:1c:f8:30:3d:b0:9b:ca:a2:81: + 72:4c:bd:60:fe:f7:21:fe:0b:db:0b:db:e9:5b:01: + 36:d4:28:15:6b:79:eb:d0:91:1b:21:59:b8:0e:aa: + bf:d5:b1:6c:70:37:a3:3f:a5:7d:0e:95:46:f6:f6: + 58:67:83:75:42:37:18:0b:a4:41:39:b2:2f:6c:80: + 2c:78:ec:a5:0f:be:9c:10:f8:c0:0b:0d:73:99:9e: + 0d:d7:97:50:cb:cc:45:34:23:49:41:85:22:24:ad: + 29:c3 + Exponent: 65537 (0x10001) + X509v3 extensions: + X509v3 Subject Key Identifier: + 95:45:7E:5F:2B:EA:65:98:12:91:04:F3:63:C7:68:9A:58:16:77:27 + + + +Jennings, et al. Informational [Page 4] + +RFC 6216 SIP Secure Call Flows April 2011 + + + X509v3 Authority Key Identifier: + 95:45:7E:5F:2B:EA:65:98:12:91:04:F3:63:C7:68:9A:58:16:77:27 + + X509v3 Basic Constraints: + CA:TRUE + Signature Algorithm: sha1WithRSAEncryption + 06:5f:9e:ae:a0:9a:bc:b5:b9:5b:7e:97:33:cc:df:63:98:98: + 94:cb:0d:66:a9:83:e8:aa:58:2a:59:a1:9e:47:31:a6:af:5c: + 3f:a2:25:86:f8:df:05:92:b7:db:69:a1:69:72:87:66:c5:ab: + 35:89:01:37:19:c9:74:eb:09:d1:3f:88:7b:24:13:42:ca:2d: + fb:45:e6:cc:4b:f8:21:78:f3:f5:97:ec:09:92:24:a2:f0:e6: + 94:8d:97:4a:00:94:00:bd:25:b8:17:2c:52:53:5d:cc:5c:48: + a4:a1:1d:2d:f6:50:55:13:a4:d3:b2:a2:f4:f1:b9:6d:48:5e: + 5c:f3:de:e0:fc:59:09:a1:d9:14:61:65:bf:d8:3f:b9:ba:2e: + 7c:ed:5c:24:9b:6b:ca:aa:5f:f1:c1:1e:b0:a8:da:82:0f:fb: + 4c:71:3b:4d:7b:38:c8:e3:8a:2a:19:34:44:26:0b:ea:f0:47: + 38:46:28:65:04:e2:01:52:dd:ec:3d:e5:f5:53:74:77:74:75: + 6d:c6:d9:c2:0a:ac:3b:b8:98:5c:55:53:34:74:52:a8:26:b1: + 2f:30:22:d0:8b:b7:f3:a0:dd:68:07:33:d5:ae:b7:81:b2:94: + 58:72:4e:7c:c6:72:2f:bd:6c:69:fb:b5:17:a8:2a:8d:d7:2c: + 91:06:c8:0c + + + The certificate content shown above and throughout this document was + rendered by the OpenSSL "x509" tool. These dumps are included only + as informative examples. Output may vary among future revisions of + the tool. At the time of this document's publication, there were + some irregularities in the presentation of Distinguished Names (DNs). + In particular, note that in the "Issuer" and "Subject" fields, it + appears the intent is to present DNs in Lightweight Directory Access + Protocol (LDAP) format. If this was intended, the spaces should have + been omitted after the delimiting commas, and the elements should + have been presented in order of most-specific to least-specific. + Please refer to Appendix A of [RFC4514]. Using the "Issuer" DN from + above as an example and following guidelines in [RFC4514], it should + have instead appeared as: + + Issuer: OU=Sipit Test Certificate Authority,O=sipit,L=San Jose, + ST=California,C=US + + The ASN.1 ([X.683]) parse of the CA certificate is shown below. + + 0:l= 949 cons: SEQUENCE + 4:l= 669 cons: SEQUENCE + 8:l= 3 cons: cont [ 0 ] + 10:l= 1 prim: INTEGER :02 + 13:l= 9 prim: INTEGER :96A384174EEF8A4C + 24:l= 13 cons: SEQUENCE + + + +Jennings, et al. Informational [Page 5] + +RFC 6216 SIP Secure Call Flows April 2011 + + + 26:l= 9 prim: OBJECT :sha1WithRSAEncryption + 37:l= 0 prim: NULL + 39:l= 112 cons: SEQUENCE + 41:l= 11 cons: SET + 43:l= 9 cons: SEQUENCE + 45:l= 3 prim: OBJECT :countryName + 50:l= 2 prim: PRINTABLESTRING :US + 54:l= 19 cons: SET + 56:l= 17 cons: SEQUENCE + 58:l= 3 prim: OBJECT :stateOrProvinceName + 63:l= 10 prim: UTF8STRING + 43 61 6c 69 66 6f 72 6e-69 61 California + 75:l= 17 cons: SET + 77:l= 15 cons: SEQUENCE + 79:l= 3 prim: OBJECT :localityName + 84:l= 8 prim: UTF8STRING + 53 61 6e 20 4a 6f 73 65- San Jose + 94:l= 14 cons: SET + 96:l= 12 cons: SEQUENCE + 98:l= 3 prim: OBJECT :organizationName +103:l= 5 prim: UTF8STRING + 73 69 70 69 74 sipit +110:l= 41 cons: SET +112:l= 39 cons: SEQUENCE +114:l= 3 prim: OBJECT :organizationalUnitName +119:l= 32 prim: UTF8STRING + 53 69 70 69 74 20 54 65-73 74 20 43 65 72 74 69 Sipit Test Certi + 66 69 63 61 74 65 20 41-75 74 68 6f 72 69 74 79 ficate Authority +153:l= 32 cons: SEQUENCE +155:l= 13 prim: UTCTIME :110127183605Z +170:l= 15 prim: GENERALIZEDTIME :21110103183605Z +187:l= 112 cons: SEQUENCE +189:l= 11 cons: SET +191:l= 9 cons: SEQUENCE +193:l= 3 prim: OBJECT :countryName +198:l= 2 prim: PRINTABLESTRING :US +202:l= 19 cons: SET +204:l= 17 cons: SEQUENCE +206:l= 3 prim: OBJECT :stateOrProvinceName +211:l= 10 prim: UTF8STRING + 43 61 6c 69 66 6f 72 6e-69 61 California +223:l= 17 cons: SET +225:l= 15 cons: SEQUENCE +227:l= 3 prim: OBJECT :localityName +232:l= 8 prim: UTF8STRING + 53 61 6e 20 4a 6f 73 65- San Jose +242:l= 14 cons: SET +244:l= 12 cons: SEQUENCE + + + +Jennings, et al. Informational [Page 6] + +RFC 6216 SIP Secure Call Flows April 2011 + + +246:l= 3 prim: OBJECT :organizationName +251:l= 5 prim: UTF8STRING + 73 69 70 69 74 sipit +258:l= 41 cons: SET +260:l= 39 cons: SEQUENCE +262:l= 3 prim: OBJECT :organizationalUnitName +267:l= 32 prim: UTF8STRING + 53 69 70 69 74 20 54 65-73 74 20 43 65 72 74 69 Sipit Test Certi + 66 69 63 61 74 65 20 41-75 74 68 6f 72 69 74 79 ficate Authority +301:l= 290 cons: SEQUENCE +305:l= 13 cons: SEQUENCE +307:l= 9 prim: OBJECT :rsaEncryption +318:l= 0 prim: NULL +320:l= 271 prim: BIT STRING + 00 30 82 01 0a 02 82 01-01 00 ab 1f 91 61 f1 1c .0...........a.. + c5 cd a6 7b 16 9b b7 14-79 e4 30 9e 98 d0 ec 07 ...{....y.0..... + b7 bd 77 d7 d1 f5 5b 2c-e2 ee e6 b1 b0 f0 85 fa ..w...[,........ + a5 bc cb cc cf 69 2c 4f-fc 50 ef 9d 31 2b c0 59 .....i,O.P..1+.Y + ea fb 64 6f 1f 55 a7 3d-fd 70 d2 56 db 14 99 17 ..do.U.=.p.V.... + 92 70 ac 26 f8 34 41 70-d9 c0 03 91 6a ba d1 11 .p.&.4Ap....j... + 8f ac 12 31 de b9 19 70-8d 5d a7 7d 8b 19 cc 40 ...1...p.].}...@ + 3f ae ff de 1f db 94 b3-46 77 6c ae ae ff 3e d6 ?.......Fwl...>. + 84 5b c2 de 0b 26 65 d0-91 c7 70 4b c7 0a 4a bf .[...&e...pK..J. + c7 97 04 dd ba 58 47 cb-e0 2b 23 76 87 65 c5 55 .....XG..+#v.e.U + 34 10 ab 27 1f 1c f8 30-3d b0 9b ca a2 81 72 4c 4..'...0=.....rL + bd 60 fe f7 21 fe 0b db-0b db e9 5b 01 36 d4 28 .`..!......[.6.( + 15 6b 79 eb d0 91 1b 21-59 b8 0e aa bf d5 b1 6c .ky....!Y......l + 70 37 a3 3f a5 7d 0e 95-46 f6 f6 58 67 83 75 42 p7.?.}..F..Xg.uB + 37 18 0b a4 41 39 b2 2f-6c 80 2c 78 ec a5 0f be 7...A9./l.,x.... + 9c 10 f8 c0 0b 0d 73 99-9e 0d d7 97 50 cb cc 45 ......s.....P..E + 34 23 49 41 85 22 24 ad-29 c3 02 03 01 00 01 4#IA."$.)...... +595:l= 80 cons: cont [ 3 ] +597:l= 78 cons: SEQUENCE +599:l= 29 cons: SEQUENCE +601:l= 3 prim: OBJECT :X509v3 Subject Key Identifier +606:l= 22 prim: OCTET STRING + 04 14 95 45 7e 5f 2b ea-65 98 12 91 04 f3 63 c7 ...E~_+.e.....c. + 68 9a 58 16 77 27 h.X.w' +630:l= 31 cons: SEQUENCE +632:l= 3 prim: OBJECT :X509v3 Authority Key Identifier +637:l= 24 prim: OCTET STRING + 30 16 80 14 95 45 7e 5f-2b ea 65 98 12 91 04 f3 0....E~_+.e..... + 63 c7 68 9a 58 16 77 27- c.h.X.w' +663:l= 12 cons: SEQUENCE +665:l= 3 prim: OBJECT :X509v3 Basic Constraints +670:l= 5 prim: OCTET STRING + 30 03 01 01 ff 0.... +677:l= 13 cons: SEQUENCE + + + +Jennings, et al. Informational [Page 7] + +RFC 6216 SIP Secure Call Flows April 2011 + + +679:l= 9 prim: OBJECT :sha1WithRSAEncryption +690:l= 0 prim: NULL +692:l= 257 prim: BIT STRING + 00 06 5f 9e ae a0 9a bc-b5 b9 5b 7e 97 33 cc df .._.......[~.3.. + 63 98 98 94 cb 0d 66 a9-83 e8 aa 58 2a 59 a1 9e c.....f....X*Y.. + 47 31 a6 af 5c 3f a2 25-86 f8 df 05 92 b7 db 69 G1..\?.%.......i + a1 69 72 87 66 c5 ab 35-89 01 37 19 c9 74 eb 09 .ir.f..5..7..t.. + d1 3f 88 7b 24 13 42 ca-2d fb 45 e6 cc 4b f8 21 .?.{$.B.-.E..K.! + 78 f3 f5 97 ec 09 92 24-a2 f0 e6 94 8d 97 4a 00 x......$......J. + 94 00 bd 25 b8 17 2c 52-53 5d cc 5c 48 a4 a1 1d ...%..,RS].\H... + 2d f6 50 55 13 a4 d3 b2-a2 f4 f1 b9 6d 48 5e 5c -.PU........mH^\ + f3 de e0 fc 59 09 a1 d9-14 61 65 bf d8 3f b9 ba ....Y....ae..?.. + 2e 7c ed 5c 24 9b 6b ca-aa 5f f1 c1 1e b0 a8 da .|.\$.k.._...... + 82 0f fb 4c 71 3b 4d 7b-38 c8 e3 8a 2a 19 34 44 ...Lq;M{8...*.4D + 26 0b ea f0 47 38 46 28-65 04 e2 01 52 dd ec 3d &...G8F(e...R..= + e5 f5 53 74 77 74 75 6d-c6 d9 c2 0a ac 3b b8 98 ..Stwtum.....;.. + 5c 55 53 34 74 52 a8 26-b1 2f 30 22 d0 8b b7 f3 \US4tR.&./0".... + a0 dd 68 07 33 d5 ae b7-81 b2 94 58 72 4e 7c c6 ..h.3......XrN|. + 72 2f bd 6c 69 fb b5 17-a8 2a 8d d7 2c 91 06 c8 r/.li....*..,... + 0c . + +2.2. Host Certificates + + The certificate for the host example.com is shown below. Note that + the Subject Alternative Name is set to example.com and is a DNS type. + The certificates for the other hosts are shown in Appendix B. + + Version: 3 (0x2) + Serial Number: + 96:a3:84:17:4e:ef:8a:4f + Signature Algorithm: sha1WithRSAEncryption + Issuer: C=US, ST=California, L=San Jose, O=sipit, + OU=Sipit Test Certificate Authority + Validity + Not Before: Feb 7 19:32:17 2011 GMT + Not After : Jan 14 19:32:17 2111 GMT + Subject: C=US, ST=California, L=San Jose, O=sipit, CN=example.com + Subject Public Key Info: + Public Key Algorithm: rsaEncryption + RSA Public Key: (2048 bit) + Modulus (2048 bit): + 00:dd:74:06:02:10:c2:e7:04:1f:bc:8c:b6:24:e7: + 9b:94:a3:48:37:85:9e:6d:83:12:84:50:1a:8e:48: + b1:fa:86:8c:a7:80:b9:be:52:ec:a6:ca:63:47:84: + ad:f6:74:85:82:16:7e:4e:36:40:0a:74:2c:20:a9: + 6a:0e:6a:7f:35:cf:70:71:63:7d:e9:43:67:81:4c: + ea:b5:1e:b7:4c:a3:35:08:7b:21:0d:2a:73:07:63: + 9d:8d:75:bf:1f:d4:8e:e6:67:60:75:f7:ea:0a:7a: + + + +Jennings, et al. Informational [Page 8] + +RFC 6216 SIP Secure Call Flows April 2011 + + + 6c:90:af:92:45:e0:62:05:9a:8a:10:98:dc:7c:54: + 8b:e4:61:95:3b:04:fc:10:50:ef:80:45:ba:5e:84: + 97:76:c1:20:25:c1:92:1d:89:0a:f7:55:62:64:fa: + e8:69:a2:62:4c:67:d3:08:d9:61:b5:3d:16:54:b6: + b7:44:8d:59:2b:90:d4:e9:fb:c7:7d:87:58:c3:12: + ac:33:78:00:50:ba:07:05:b3:b9:01:1a:63:55:6c: + e1:7a:ec:a3:07:ae:3b:02:83:a1:69:e0:c3:dc:2d: + 61:e9:b2:e3:b3:71:c8:a6:cf:da:fb:3e:99:c7:e5: + 71:b9:c9:17:d4:ed:bc:a0:47:54:09:8c:6e:6d:53: + 9a:2c:c9:68:c6:6f:f1:3d:91:1a:24:43:77:7d:91: + 69:4b + Exponent: 65537 (0x10001) + X509v3 extensions: + X509v3 Subject Alternative Name: + DNS:example.com, URI:sip:example.com + X509v3 Basic Constraints: + CA:FALSE + X509v3 Subject Key Identifier: + CC:06:59:5B:8B:5E:D6:0D:F2:05:4D:1B:68:54:1E:FC:F9:43:19:17 + X509v3 Authority Key Identifier: + 95:45:7E:5F:2B:EA:65:98:12:91:04:F3:63:C7:68:9A:58:16:77:27 + + X509v3 Key Usage: + Digital Signature, Non Repudiation, Key Encipherment + X509v3 Extended Key Usage: + TLS Web Server Authentication, 1.3.6.1.5.5.7.3.20 + Signature Algorithm: sha1WithRSAEncryption + 6a:9a:d1:db:00:4b:90:86:b0:53:ea:6f:30:31:89:1e:9b:09: + 14:bd:6f:b9:02:aa:6f:58:ee:30:03:b8:a1:fd:b3:41:72:ff: + b3:0d:cb:76:a7:17:c6:57:38:06:13:e5:f3:e4:30:17:4d:f7: + 97:b5:f3:74:e9:81:f8:f4:55:a3:0d:f5:82:38:c3:98:43:52: + 1f:84:cd:1a:b4:a3:45:9f:3d:e2:31:fd:cb:a2:ad:ed:60:7d: + fa:d2:aa:49:2f:41:a9:80:01:bb:ed:b6:75:c9:97:69:7f:0c: + 91:60:f1:c4:5a:36:e8:5c:ac:e1:a8:e7:9a:55:e5:e0:cd:01: + f4:de:93:f4:38:6c:c1:71:d2:fd:cd:1b:5d:25:eb:90:7b:31: + 41:e7:37:0e:e5:c0:01:48:91:f7:34:dd:c6:1f:74:e6:34:34: + e6:cd:93:0f:3f:ce:94:ad:91:d9:e2:72:b1:9f:1d:d3:a5:7d: + 5e:e2:a4:56:c5:b1:71:4d:10:0a:5d:a6:56:e6:57:1f:48:a5: + 5c:75:67:ea:ab:35:3e:f6:b6:fa:c1:f3:8a:c1:80:71:32:18: + 6c:33:b5:fa:16:5a:16:e1:a1:6c:19:67:f5:45:68:64:6f:b2: + 31:dc:e3:5a:1a:b2:d4:87:89:96:fd:87:ba:38:4e:0a:19:07: + 03:4b:9b:b1 + + The example host certificate above, as well as all the others + presented in this document, are signed directly by a root CA. These + certificate chains have a length equal to two: the root CA and the + host certificate. Non-root CAs exist and may also sign certificates. + The certificate chains presented by hosts with certificates signed by + + + +Jennings, et al. Informational [Page 9] + +RFC 6216 SIP Secure Call Flows April 2011 + + + non-root CAs will have a length greater than two. For more details + on how certificate chains are validated, see Sections 6.1 and 6.2 of + [RFC5280]. + +2.3. User Certificates + + User certificates are used by many applications to establish user + identity. The user certificate for fluffy@example.com is shown + below. Note that the Subject Alternative Name has a list of names + with different URL types such as a sip, im, or pres URL. This is + necessary for interoperating with a Common Profile for Instant + Messaging (CPIM) gateway. In this example, example.com is the domain + for fluffy. The message could be coming from any host in + *.example.com, and the address-of-record (AOR) in the user + certificate would still be the same. The others are shown in + Appendix B.1. These certificates make use of the Extended Key Usage + (EKU) extension discussed in [RFC5924]. Note that the X509v3 + Extended Key Usage attribute refers to the SIP OID introduced in + [RFC5924], which is 1.3.6.1.5.5.7.3.20. + + Version: 3 (0x2) + Serial Number: + 96:a3:84:17:4e:ef:8a:4d + Signature Algorithm: sha1WithRSAEncryption + Issuer: C=US, ST=California, L=San Jose, O=sipit, + OU=Sipit Test Certificate Authority + Validity + Not Before: Feb 7 19:32:17 2011 GMT + Not After : Jan 14 19:32:17 2111 GMT + Subject: C=US, ST=California, L=San Jose, O=sipit, + CN=fluffy + Subject Public Key Info: + Public Key Algorithm: rsaEncryption + RSA Public Key: (2048 bit) + Modulus (2048 bit): + 00:a3:2c:59:0c:e9:bc:e4:ec:d3:9e:fb:99:02:ec: + b1:36:3a:b7:d3:1d:4d:c3:3a:b6:ae:50:bd:5f:55: + 08:77:8c:7e:a4:e9:f0:68:31:28:8f:23:32:56:19: + c3:22:97:a7:6d:fd:a7:22:2a:01:b5:af:61:bd:5f: + 7e:c1:14:e5:98:29:b4:34:4e:38:8a:26:ee:0d:da: + db:27:b9:78:d6:ac:ac:04:78:32:98:c2:75:e7:6a: + b7:2d:b3:3c:e3:eb:97:a5:ef:8b:59:42:50:17:7b: + fe:a7:81:af:37:a7:e7:e3:1f:b0:8d:d0:72:2f:6c: + 14:42:c6:01:68:e1:8f:fd:56:4d:7d:cf:16:dc:aa: + 05:61:0b:0a:ca:ca:ec:51:ec:53:6e:3d:2b:00:80: + fe:35:1b:06:0a:61:13:88:0b:44:f3:cc:fd:2b:0e: + b4:a2:0b:a0:97:84:14:2e:ee:2b:e3:2f:c1:1a:9e: + 86:9a:78:6a:a2:4c:57:93:e7:01:26:d3:56:0d:bd: + + + +Jennings, et al. Informational [Page 10] + +RFC 6216 SIP Secure Call Flows April 2011 + + + b0:2f:f8:da:c7:3c:01:dc:cb:2d:31:8c:6c:c6:5c: + b4:63:e8:b2:a2:40:11:bf:ad:f8:6d:12:01:97:1d: + 47:f8:6a:15:8b:fb:27:96:73:44:46:34:d7:24:1c: + cf:56:8d:d4:be:d6:94:5b:f0:a6:67:e3:dd:cf:b4: + f2:d5 + Exponent: 65537 (0x10001) + X509v3 extensions: + X509v3 Subject Alternative Name: + URI:sip:fluffy@example.com, URI:im:fluffy@example.com, + URI:pres:fluffy@example.com + X509v3 Basic Constraints: + CA:FALSE + X509v3 Subject Key Identifier: + 85:97:09:B8:D3:55:37:24:8A:DC:DE:E3:91:72:E4:22:CF:98:87:52 + X509v3 Authority Key Identifier: + 95:45:7E:5F:2B:EA:65:98:12:91:04:F3:63:C7:68:9A:58:16:77:27 + + X509v3 Key Usage: + Digital Signature, Non Repudiation, Key Encipherment + X509v3 Extended Key Usage: + E-mail Protection, 1.3.6.1.5.5.7.3.20 + Signature Algorithm: sha1WithRSAEncryption + a8:a9:8f:d8:8a:0b:88:ed:ff:4f:bf:e5:cd:8f:9e:7b:b8:e6: + f2:2c:aa:e3:23:5b:9a:71:5e:fd:20:a3:dd:d9:d3:c1:f2:e8: + f0:be:77:db:33:cc:8a:7b:4f:91:2b:8d:d6:f7:14:c3:8d:e0: + 60:d3:34:50:bc:be:67:22:cd:f5:74:7b:f4:9a:68:a2:52:2b: + 81:2f:46:d3:09:9f:25:c3:20:e8:10:d5:ef:38:7b:d1:17:d4: + f1:d7:54:67:56:f1:13:cf:2f:fc:8b:83:fc:14:e7:01:82:59: + 83:cc:b1:8d:f0:c7:da:4e:b1:dc:cc:54:cf:6c:3b:47:47:59: + 87:d9:16:ec:af:af:e1:12:13:23:1e:0a:db:f5:b5:ff:5d:ab: + 15:0e:e3:25:91:00:0e:90:db:d8:07:11:90:81:01:3a:48:a8: + aa:9e:b0:62:d3:36:f0:0c:b7:2f:a7:17:92:52:36:29:14:0a: + d6:65:86:67:73:74:6e:aa:3c:ee:47:38:1e:c8:6e:06:81:85: + 1c:2e:f0:b6:04:7d:6c:38:db:81:9c:b8:07:e3:07:be:f5:2f: + 09:68:63:04:6b:87:0e:36:b9:a1:a3:fb:c8:30:0c:a0:63:8d: + 6d:ab:0a:f8:44:b0:78:19:1a:38:7e:fa:6a:a1:d4:4b:4b:75: + 75:bf:6f:09 + + Versions of these certificates that do not make use of EKU are also + included in Appendix B.2 + + + + + + + + + + + +Jennings, et al. Informational [Page 11] + +RFC 6216 SIP Secure Call Flows April 2011 + + +3. Call Flow with Message Over TLS + +3.1. TLS with Server Authentication + + The flow below shows the edited SSLDump output of the host + example.com forming a TLS [RFC5246] connection to example.net. In + this example, mutual authentication is not used. Note that the + client proposed three protocol suites including + TLS_RSA_WITH_AES_128_CBC_SHA defined in [RFC5246]. The certificate + returned by the server contains a Subject Alternative Name that is + set to example.net. A detailed discussion of TLS can be found in SSL + and TLS [EKR-TLS]. For more details on the SSLDump tool, see the + SSLDump Manual [ssldump-manpage]. + + This example does not use the Server Extended Hello (see [RFC5246]). + + New TCP connection #1: example.com(50738) <-> example.net(5061) + 1 1 0.0004 (0.0004) C>SV3.1(101) Handshake + ClientHello + Version 3.1 + random[32]= + 4c 09 5b a7 66 77 eb 43 52 30 dd 98 4d 09 23 d3 + ff 81 74 ab 04 69 bb 79 8c dc 59 cd c2 1f b7 ec + cipher suites + TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA + TLS_ECDH_RSA_WITH_AES_256_CBC_SHA + TLS_DHE_RSA_WITH_AES_256_SHA + TLS_RSA_WITH_AES_256_CBC_SHA + TLS_DSS_RSA_WITH_AES_256_SHA + TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA + TLS_ECDH_RSA_WITH_AES_128_CBC_SHA + TLS_DHE_RSA_WITH_AES_128_CBC_SHA + TLS_RSA_WITH_AES_128_CBC_SHA + TLS_DHE_DSS_WITH_AES_128_CBC_SHA + TLS_ECDHE_RSA_WITH_DES_192_CBC3_SHA + TLS_ECDH_RSA_WITH_DES_192_CBC3_SHA + TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA + TLS_RSA_WITH_3DES_EDE_CBC_SHA + TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA + TLS_ECDHE_RSA_WITH_RC4_128_SHA + TLS_ECDH_RSA_WITH_RC4_128_SHA + TLS_RSA_WITH_RC4_128_SHA + TLS_RSA_WITH_RC4_128_MD5 + TLS_DHE_RSA_WITH_DES_CBC_SHA + TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA + TLS_RSA_WITH_DES_CBC_SHA + TLS_RSA_EXPORT_WITH_DES40_CBC_SHA + TLS_DHE_DSS_WITH_DES_CBC_SHA + + + +Jennings, et al. Informational [Page 12] + +RFC 6216 SIP Secure Call Flows April 2011 + + + TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA + TLS_RSA_EXPORT_WITH_RC4_40_MD5 + compression methods + NULL + 1 2 0.0012 (0.0007) S>CV3.1(48) Handshake + ServerHello + Version 3.1 + random[32]= + 4c 09 5b a7 30 87 74 c7 16 98 24 d5 af 35 17 a7 + ef c3 78 0c 94 d4 94 d2 7b a6 3f 40 04 25 f6 e0 + session_id[0]= + + cipherSuite TLS_RSA_WITH_AES_256_CBC_SHA + compressionMethod NULL + 1 3 0.0012 (0.0000) S>CV3.1(1858) Handshake + Certificate + 1 4 0.0012 (0.0000) S>CV3.1(14) Handshake + CertificateRequest + certificate_types rsa_sign + certificate_types dss_sign + certificate_types unknown value + ServerHelloDone + 1 5 0.0043 (0.0031) C>SV3.1(7) Handshake + Certificate + 1 6 0.0043 (0.0000) C>SV3.1(262) Handshake + ClientKeyExchange + 1 7 0.0043 (0.0000) C>SV3.1(1) ChangeCipherSpec + 1 8 0.0043 (0.0000) C>SV3.1(48) Handshake + 1 9 0.0129 (0.0085) S>CV3.1(170) Handshake + 1 10 0.0129 (0.0000) S>CV3.1(1) ChangeCipherSpec + 1 11 0.0129 (0.0000) S>CV3.1(48) Handshake + 1 12 0.0134 (0.0005) C>SV3.1(32) application_data + 1 13 0.0134 (0.0000) C>SV3.1(496) application_data + 1 14 0.2150 (0.2016) S>CV3.1(32) application_data + 1 15 0.2150 (0.0000) S>CV3.1(336) application_data + 1 16 12.2304 (12.0154) S>CV3.1(32) Alert + 1 12.2310 (0.0005) S>C TCP FIN + 1 17 12.2321 (0.0011) C>SV3.1(32) Alert + +3.2. MESSAGE Transaction Over TLS + + Once the TLS session is set up, the following MESSAGE request (as + defined in [RFC3428] is sent from fluffy@example.com to + kumiko@example.net. Note that the URI has a SIPS URL and that the + VIA indicates that TLS was used. In order to format this document, + the convention from [RFC4475] is used to break long + lines. The actual message does not contain the line breaks contained + within those tags. + + + +Jennings, et al. Informational [Page 13] + +RFC 6216 SIP Secure Call Flows April 2011 + + + MESSAGE sips:kumiko@example.net:5061 SIP/2.0 + + Via: SIP/2.0/TLS 192.0.2.2:15001; + branch=z9hG4bK-d8754z-c785a077a9a8451b-1---d8754z-; + rport=50738 + + Max-Forwards: 70 + To: + From: ;tag=1a93430b + Call-ID: OTZmMDE2OWNlYTVjNDkzYzBhMWRlMDU4NDExZmU4ZTQ. + CSeq: 4308 MESSAGE + + Accept: multipart/signed, text/plain, application/pkcs7-mime, + application/sdp, multipart/alternative + + Content-Type: text/plain + Content-Length: 6 + + Hello! + + When a User Agent (UA) goes to send a message to example.com, the UA + can see if it already has a TLS connection to example.com and if it + does, it may send the message over this connection. A UA should have + some scheme for reusing connections as opening a new TLS connection + for every message results in awful performance. Implementers are + encouraged to read [RFC5923] and [RFC3263]. + + The response is sent from example.net to example.com over the same + TLS connection. It is shown below. + + SIP/2.0 200 OK + + Via: SIP/2.0/TLS 192.0.2.2:15001; + branch=z9hG4bK-d8754z-c785a077a9a8451b-1---d8754z-; + rport=50738 + + To: ;tag=0d075510 + From: ;tag=1a93430b + Call-ID: OTZmMDE2OWNlYTVjNDkzYzBhMWRlMDU4NDExZmU4ZTQ. + CSeq: 4308 MESSAGE + Content-Length: 0 + + + + + + + + + + +Jennings, et al. Informational [Page 14] + +RFC 6216 SIP Secure Call Flows April 2011 + + +4. Call Flow with S/MIME-Secured Message + +4.1. MESSAGE Request with Signed Body + + Below is an example of a signed message. The values on the Content- + Type line (multipart/signed) and on the Content-Disposition line have + been broken across lines to fit on the page, but they are not broken + across lines in actual implementations. + + MESSAGE sip:kumiko@example.net SIP/2.0 + + Via: SIP/2.0/TCP 192.0.2.2:15001; + branch=z9hG4bK-d8754z-3a922b6dc0f0ff37-1---d8754z-; + rport=50739 + + Max-Forwards: 70 + To: + From: ;tag=ef6bad5e + Call-ID: N2NiZjI0NjRjNDQ0MTY1NDRjNWNmMGU1MDA2MDRhYmI. + CSeq: 8473 MESSAGE + + Accept: multipart/signed, text/plain, application/pkcs7-mime, + application/sdp, multipart/alternative + + + Content-Type: multipart/signed;boundary=3b515e121b43a911; + micalg=sha1;protocol="application/pkcs7-signature" + + Content-Length: 774 + + --3b515e121b43a911 + Content-Type: text/plain + Content-Transfer-Encoding: binary + + Hello! + --3b515e121b43a911 + Content-Type: application/pkcs7-signature;name=smime.p7s + + Content-Disposition: attachment;handling=required; + filename=smime.p7s + + Content-Transfer-Encoding: binary + + ***************** + * BINARY BLOB 1 * + ***************** + --3b515e121b43a911-- + + + + +Jennings, et al. Informational [Page 15] + +RFC 6216 SIP Secure Call Flows April 2011 + + + It is important to note that the signature ("BINARY BLOB 1") is + computed over the MIME headers and body, but excludes the multipart + boundary lines. The value on the Message-body line ends with CRLF. + The CRLF is included in the boundary and is not part of the signature + computation. To be clear, the signature is computed over data + starting with the "C" in the "Content-Type" and ending with the "!" + in the "Hello!". + + Content-Type: text/plain + Content-Transfer-Encoding: binary + + Hello! + + Following is the ASN.1 parsing of encrypted contents referred to + above as "BINARY BLOB 1". Note that at address 30, the hash for the + signature is specified as SHA-1. Also note that the sender's + certificate is not attached as it is optional in [RFC5652]. + + 0 472: SEQUENCE { + 4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) + 15 457: [0] { + 19 453: SEQUENCE { + 23 1: INTEGER 1 + 26 11: SET { + 28 9: SEQUENCE { + 30 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) + 37 0: NULL + : } + : } + 39 11: SEQUENCE { + 41 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) + : } + 52 420: SET { + 56 416: SEQUENCE { + 60 1: INTEGER 1 + 63 125: SEQUENCE { + 65 112: SEQUENCE { + 67 11: SET { + 69 9: SEQUENCE { + 71 3: OBJECT IDENTIFIER countryName (2 5 4 6) + 76 2: PrintableString 'US' + : } + : } + 80 19: SET { + 82 17: SEQUENCE { + 84 3: OBJECT IDENTIFIER + : stateOrProvinceName (2 5 4 8) + 89 10: UTF8String 'California' + + + +Jennings, et al. Informational [Page 16] + +RFC 6216 SIP Secure Call Flows April 2011 + + + : } + : } + 101 17: SET { + 103 15: SEQUENCE { + 105 3: OBJECT IDENTIFIER localityName (2 5 4 7) + 110 8: UTF8String 'San Jose' + : } + : } + 120 14: SET { + 122 12: SEQUENCE { + 124 3: OBJECT IDENTIFIER + : organizationName (2 5 4 10) + 129 5: UTF8String 'sipit' + : } + : } + 136 41: SET { + 138 39: SEQUENCE { + 140 3: OBJECT IDENTIFIER + : organizationalUnitName (2 5 4 11) + 145 32: UTF8String 'Sipit Test Certificate + Authority' + : } + : } + : } + 179 9: INTEGER 00 96 A3 84 17 4E EF 8A 4D + : } + 190 9: SEQUENCE { + 192 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) + 199 0: NULL + : } + 201 13: SEQUENCE { + 203 9: OBJECT IDENTIFIER + : rsaEncryption (1 2 840 113549 1 1 1) + 214 0: NULL + : } + 216 256: OCTET STRING + : 74 4D 21 39 D6 E2 E2 2C 30 5A AA BC 4E 60 8D 69 + : A7 E5 79 50 1A B1 7D 4A D3 C1 03 9F 19 7D A2 76 + : 97 B3 CE 30 CD 62 4B 96 20 35 DB C1 64 D9 33 92 + : 96 CD 28 03 98 6E 2C 0C F6 8D 93 40 F2 88 DA 29 + : AD 0B C2 0E F9 D3 6A 95 2C 79 6E C2 3D 62 E6 54 + : A9 1B AC 66 DB 16 B7 44 6C 03 1B 71 9C EE C9 EC + : 4D 93 B1 CF F5 17 79 C5 C8 BA 2F A7 6C 4B DC CF + : 62 A3 F3 1A 1B 24 E4 40 66 3C 4F 87 86 BF 09 6A + : 7A 43 60 2B FC D8 3D 2B 57 17 CB 81 03 2A 56 69 + : 81 82 FA 78 DE D2 3A 2F FA A3 C5 EA 8B E8 0C 36 + : 1B BC DC FD 1B 8C 2E 0F 01 AF D9 E1 04 0E 4E 50 + : 94 75 7C BD D9 0B DD AA FA 36 E3 EC E4 A5 35 46 + + + +Jennings, et al. Informational [Page 17] + +RFC 6216 SIP Secure Call Flows April 2011 + + + : BE A2 97 1D AD BA 44 54 3A ED 94 DA 76 4A 51 BA + : A4 7D 7A 62 BF 2A 2F F2 5C 5A FE CA E6 B9 DC 5D + : EA 26 F2 35 17 19 20 CE 97 96 4E 72 9C 72 FD 1F + : 68 C1 6A 5C 86 42 F2 ED F2 70 65 4C C7 44 C5 7C + : } + : } + : } + : } + : } + + SHA-1 parameters may be omitted entirely, instead of being set to + NULL, as mentioned in [RFC3370]. The above dump of Blob 1 has SHA-1 + parameters set to NULL. Below are the same contents signed with the + same key, but omitting the NULL according to [RFC3370]. This is the + preferred encoding. This is covered in greater detail in Section 5. + + 0 468: SEQUENCE { + 4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) + 15 453: [0] { + 19 449: SEQUENCE { + 23 1: INTEGER 1 + 26 9: SET { + 28 7: SEQUENCE { + 30 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) + : } + : } + 37 11: SEQUENCE { + 39 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) + : } + 50 418: SET { + 54 414: SEQUENCE { + 58 1: INTEGER 1 + 61 125: SEQUENCE { + 63 112: SEQUENCE { + 65 11: SET { + 67 9: SEQUENCE { + 69 3: OBJECT IDENTIFIER countryName (2 5 4 6) + 74 2: PrintableString 'US' + : } + : } + 78 19: SET { + 80 17: SEQUENCE { + 82 3: OBJECT IDENTIFIER + : stateOrProvinceName (2 5 4 8) + 87 10: UTF8String 'California' + : } + : } + 99 17: SET { + + + +Jennings, et al. Informational [Page 18] + +RFC 6216 SIP Secure Call Flows April 2011 + + + 101 15: SEQUENCE { + 103 3: OBJECT IDENTIFIER localityName (2 5 4 7) + 108 8: UTF8String 'San Jose' + : } + : } + 118 14: SET { + 120 12: SEQUENCE { + 122 3: OBJECT IDENTIFIER + : organizationName (2 5 4 10) + 127 5: UTF8String 'sipit' + : } + : } + 134 41: SET { + 136 39: SEQUENCE { + 138 3: OBJECT IDENTIFIER + : organizationalUnitName (2 5 4 11) + 143 32: UTF8String 'Sipit Test Certificate + Authority' + : } + : } + : } + 177 9: INTEGER 00 96 A3 84 17 4E EF 8A 4D + : } + 188 7: SEQUENCE { + 190 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) + : } + 197 13: SEQUENCE { + 199 9: OBJECT IDENTIFIER + : rsaEncryption (1 2 840 113549 1 1 1) + 210 0: NULL + : } + 212 256: OCTET STRING + : 74 4D 21 39 D6 E2 E2 2C 30 5A AA BC 4E 60 8D 69 + : A7 E5 79 50 1A B1 7D 4A D3 C1 03 9F 19 7D A2 76 + : 97 B3 CE 30 CD 62 4B 96 20 35 DB C1 64 D9 33 92 + : 96 CD 28 03 98 6E 2C 0C F6 8D 93 40 F2 88 DA 29 + : AD 0B C2 0E F9 D3 6A 95 2C 79 6E C2 3D 62 E6 54 + : A9 1B AC 66 DB 16 B7 44 6C 03 1B 71 9C EE C9 EC + : 4D 93 B1 CF F5 17 79 C5 C8 BA 2F A7 6C 4B DC CF + : 62 A3 F3 1A 1B 24 E4 40 66 3C 4F 87 86 BF 09 6A + : 7A 43 60 2B FC D8 3D 2B 57 17 CB 81 03 2A 56 69 + : 81 82 FA 78 DE D2 3A 2F FA A3 C5 EA 8B E8 0C 36 + : 1B BC DC FD 1B 8C 2E 0F 01 AF D9 E1 04 0E 4E 50 + : 94 75 7C BD D9 0B DD AA FA 36 E3 EC E4 A5 35 46 + : BE A2 97 1D AD BA 44 54 3A ED 94 DA 76 4A 51 BA + : A4 7D 7A 62 BF 2A 2F F2 5C 5A FE CA E6 B9 DC 5D + : EA 26 F2 35 17 19 20 CE 97 96 4E 72 9C 72 FD 1F + : 68 C1 6A 5C 86 42 F2 ED F2 70 65 4C C7 44 C5 7C + + + +Jennings, et al. Informational [Page 19] + +RFC 6216 SIP Secure Call Flows April 2011 + + + : } + : } + : } + : } + : } + +4.2. MESSAGE Request with Encrypted Body + + Below is an example of an encrypted text/plain message that says + "Hello!". The binary encrypted contents have been replaced with the + block "BINARY BLOB 2". + + MESSAGE sip:kumiko@example.net SIP/2.0 + + Via: SIP/2.0/TCP 192.0.2.2:15001; + branch=z9hG4bK-d8754z-c276232b541dd527-1---d8754z-; + rport=50741 + + Max-Forwards: 70 + To: + From: ;tag=7a2e3025 + Call-ID: MDYyMDhhODA3NWE2ZjEyYzAwOTZlMjExNWI2ZWQwZGM. + CSeq: 3260 MESSAGE + + Accept: multipart/signed, text/plain, application/pkcs7-mime, + application/sdp, multipart/alternative + + + Content-Disposition: attachment;handling=required; + filename=smime.p7 + + Content-Transfer-Encoding: binary + + Content-Type: application/pkcs7-mime;smime-type=enveloped-data; + name=smime.p7m + + Content-Length: 565 + + ***************** + * BINARY BLOB 2 * + ***************** + + Following is the ASN.1 parsing of "BINARY BLOB 2". Note that at + address 454, the encryption is set to aes128-CBC. + + 0 561: SEQUENCE { + 4 9: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3) + 15 546: [0] { + + + +Jennings, et al. Informational [Page 20] + +RFC 6216 SIP Secure Call Flows April 2011 + + + 19 542: SEQUENCE { + 23 1: INTEGER 0 + 26 409: SET { + 30 405: SEQUENCE { + 34 1: INTEGER 0 + 37 125: SEQUENCE { + 39 112: SEQUENCE { + 41 11: SET { + 43 9: SEQUENCE { + 45 3: OBJECT IDENTIFIER countryName (2 5 4 6) + 50 2: PrintableString 'US' + : } + : } + 54 19: SET { + 56 17: SEQUENCE { + 58 3: OBJECT IDENTIFIER + : stateOrProvinceName (2 5 4 8) + 63 10: UTF8String 'California' + : } + : } + 75 17: SET { + 77 15: SEQUENCE { + 79 3: OBJECT IDENTIFIER localityName (2 5 4 7) + 84 8: UTF8String 'San Jose' + : } + : } + 94 14: SET { + 96 12: SEQUENCE { + 98 3: OBJECT IDENTIFIER + : organizationName (2 5 4 10) + 103 5: UTF8String 'sipit' + : } + : } + 110 41: SET { + 112 39: SEQUENCE { + 114 3: OBJECT IDENTIFIER + : organizationalUnitName (2 5 4 11) + 119 32: UTF8String 'Sipit Test Certificate + Authority' + : } + : } + : } + 153 9: INTEGER 00 96 A3 84 17 4E EF 8A 4E + : } + 164 13: SEQUENCE { + 166 9: OBJECT IDENTIFIER + : rsaEncryption (1 2 840 113549 1 1 1) + 177 0: NULL + + + +Jennings, et al. Informational [Page 21] + +RFC 6216 SIP Secure Call Flows April 2011 + + + : } + 179 256: OCTET STRING + : B9 12 8F 32 AB 4A E2 38 C1 E0 53 69 88 D6 25 E7 + : 40 03 B1 DE 79 21 A3 E8 23 5A 1B CB FB 58 F4 97 + : 48 A7 C8 F0 3D DF 41 A3 5A 90 32 70 82 FA B0 DE + : D8 94 7C 6C 2E 01 FE 33 BD 62 CB 07 4F 58 DE 6F + : EA 3F EF B4 FB 46 72 58 9A 88 A0 85 BC 23 D7 C8 + : 09 0B 90 8D 4A 5F 3F 96 7C AC D4 E2 19 E8 02 B6 + : 0E F3 0D F2 91 4A 67 A9 EE 51 6A 97 D7 86 6D EC + : 78 6E C6 E0 83 7C E1 00 1F 5A 40 59 60 0C D7 EB + : A3 FB 04 B3 C9 A5 EB 79 ED B3 56 F8 F6 51 B2 5E + : 58 E2 D8 17 28 33 A6 B8 35 8C 0E 14 7F 90 D0 7B + : 03 00 6C 3D 81 29 F5 D7 E5 AC 75 5E E0 F0 DD E3 + : 3E B2 06 97 D6 49 A9 CB 38 08 F1 84 05 F5 C0 BC + : 55 A6 D4 C9 D8 FD A4 AC 40 9F 9D 51 5B F7 3A C3 + : C3 CD 3A E7 6D 21 05 D0 50 75 4F 14 D8 77 76 C6 + : 13 A6 48 12 7B 25 CC 22 5D 73 BD 40 E4 15 02 A2 + : 39 4A CB D9 55 08 A4 EE 4E 8A 5E BA C4 4A 46 9C + : } + : } + 439 124: SEQUENCE { + 441 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) + 452 29: SEQUENCE { + 454 9: OBJECT IDENTIFIER + : aes128-CBC (2 16 840 1 101 3 4 1 2) + 465 16: OCTET STRING + : CA 35 CA BD 1E 78 83 D9 20 6C 47 B9 9F DC 91 88 + : } + 483 80: [0] + : 1B AE 12 C4 0E 55 96 AB 99 CC 1C 7F B5 98 A4 BF + : D2 D8 7F 94 BB B5 38 05 59 F2 38 A1 CD 29 75 17 + : 1D 63 1B 0B B0 2D 88 06 7F 78 80 F3 5A 3E DC 35 + : BF 22 1E 03 32 59 98 DA FD 81 5F D9 41 63 3A 18 + : FD B5 84 14 01 46 0B 40 EB 56 29 86 47 8B D1 EE + : } + : } + : } + : } + +4.3. MESSAGE Request with Encrypted and Signed Body + + In the example below, some of the header values have been split + across multiple lines. Where the lines have been broken, the + convention has been used. This was only done to make it + fit in the RFC format. Specifically, the application/pkcs7-mime + Content-Type line is one line with no whitespace between the "mime;" + and the "smime-type". The values are split across lines for + formatting, but are not split in the real message. The binary + + + +Jennings, et al. Informational [Page 22] + +RFC 6216 SIP Secure Call Flows April 2011 + + + encrypted content has been replaced with "BINARY BLOB 3", and the + binary signed content has been replaced with "BINARY BLOB 4". + + MESSAGE sip:kumiko@example.net SIP/2.0 + + Via: SIP/2.0/TCP 192.0.2.2:15001; + branch=z9hG4bK-d8754z-97a26e59b7262b34-1---d8754z-; + rport=50742 + + Max-Forwards: 70 + To: + From: ;tag=379f5b27 + Call-ID: MjYwMzdjYTY3YWRkYzgzMjU0MGI4Mzc2Njk1YzJlNzE. + CSeq: 5449 MESSAGE + + Accept: multipart/signed, text/plain, application/pkcs7-mime, + application/sdp, multipart/alternative + + + Content-Type: multipart/signed;boundary=e8df6e1ce5d1e864; + micalg=sha1;protocol="application/pkcs7-signature" + + Content-Length: 1455 + + --e8df6e1ce5d1e864 + + Content-Type: application/pkcs7-mime;smime-type=enveloped-data; + name=smime.p7m + + + Content-Disposition: attachment;handling=required; + filename=smime.p7 + + Content-Transfer-Encoding: binary + + ***************** + * BINARY BLOB 3 * + ***************** + --e8df6e1ce5d1e864 + Content-Type: application/pkcs7-signature;name=smime.p7s + + Content-Disposition: attachment;handling=required; + filename=smime.p7s + + Content-Transfer-Encoding: binary + + ***************** + * BINARY BLOB 4 * + + + +Jennings, et al. Informational [Page 23] + +RFC 6216 SIP Secure Call Flows April 2011 + + + ***************** + --e8df6e1ce5d1e864-- + + Below is the ASN.1 parsing of "BINARY BLOB 3". + + 0 561: SEQUENCE { + 4 9: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3) + 15 546: [0] { + 19 542: SEQUENCE { + 23 1: INTEGER 0 + 26 409: SET { + 30 405: SEQUENCE { + 34 1: INTEGER 0 + 37 125: SEQUENCE { + 39 112: SEQUENCE { + 41 11: SET { + 43 9: SEQUENCE { + 45 3: OBJECT IDENTIFIER countryName (2 5 4 6) + 50 2: PrintableString 'US' + : } + : } + 54 19: SET { + 56 17: SEQUENCE { + 58 3: OBJECT IDENTIFIER + : stateOrProvinceName (2 5 4 8) + 63 10: UTF8String 'California' + : } + : } + 75 17: SET { + 77 15: SEQUENCE { + 79 3: OBJECT IDENTIFIER localityName (2 5 4 7) + 84 8: UTF8String 'San Jose' + : } + : } + 94 14: SET { + 96 12: SEQUENCE { + 98 3: OBJECT IDENTIFIER + : organizationName (2 5 4 10) + 103 5: UTF8String 'sipit' + : } + : } + 110 41: SET { + 112 39: SEQUENCE { + 114 3: OBJECT IDENTIFIER + : organizationalUnitName (2 5 4 11) + 119 32: UTF8String 'Sipit Test Certificate + Authority' + : } + + + +Jennings, et al. Informational [Page 24] + +RFC 6216 SIP Secure Call Flows April 2011 + + + : } + : } + 153 9: INTEGER 00 96 A3 84 17 4E EF 8A 4E + : } + 164 13: SEQUENCE { + 166 9: OBJECT IDENTIFIER + : rsaEncryption (1 2 840 113549 1 1 1) + 177 0: NULL + : } + 179 256: OCTET STRING + : 49 11 0B 11 52 A9 9D E3 AA FB 86 CB EB 12 CC 8E + : 96 9D 85 3E 80 D2 7C C4 9B B7 81 4B B5 FA 13 80 + : 6A 6A B2 34 72 D8 C0 82 60 DA B3 43 F8 51 8C 32 + : 8B DD D0 76 6D 9C 46 73 C1 44 A0 10 FF 16 A4 83 + : 74 85 21 74 7D E0 FD 42 C0 97 00 82 A2 80 81 22 + : 9C A2 82 0A 85 F0 68 EF 9A D7 6D 1D 24 2B A9 5E + : B3 9A A0 3E A7 D9 1D 1C D7 42 CB 6F A5 81 66 23 + : 28 00 7C 99 6A B6 03 3F 7E F6 48 EA 91 49 35 F1 + : FD 40 54 5D AC F7 84 EA 3F 27 43 FD DE E2 10 DD + : 63 C4 35 4A 13 63 0B 6D 0D 9A D5 AB 72 39 69 8C + : 65 4C 44 C4 A3 31 60 79 B9 A8 A3 A1 03 FD 41 25 + : 12 E5 F3 F8 47 CE 8C 42 D9 26 77 A5 57 AF 1A 95 + : BF 05 A5 E9 47 F2 D1 AE DC 13 7E 1B 83 5C 8C C4 + : 1F 31 BC 59 E6 FD 6E 9A B0 91 EC 71 A6 7F 28 3E + : 23 1B 40 E2 C0 60 CF 5E 5B 86 08 06 82 B4 B7 DB + : 00 DD AC 3A 39 27 E2 7C 96 AD 8A E9 C3 B8 06 5E + : } + : } + 439 124: SEQUENCE { + 441 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) + 452 29: SEQUENCE { + 454 9: OBJECT IDENTIFIER + : aes128-CBC (2 16 840 1 101 3 4 1 2) + 465 16: OCTET STRING + : 88 9B 13 75 A7 66 14 C3 CF CD C6 FF D2 91 5D A0 + : } + 483 80: [0] + : 80 0B A3 B7 57 89 B4 F4 70 AE 1D 14 A9 35 DD F9 + : 1D 66 29 46 52 40 13 E1 3B 4A 23 E5 EC AB F9 35 + : A6 B6 A4 BE C0 02 31 06 19 C4 39 22 7D 10 4C 0D + : F4 96 04 78 11 85 4E 7E E3 C3 BC B2 DF 55 17 79 + : 5F F2 4E E5 25 42 37 45 39 5D F6 DA 57 9A 4E 0B + : } + : } + : } + : } + + + + + +Jennings, et al. Informational [Page 25] + +RFC 6216 SIP Secure Call Flows April 2011 + + + Below is the ASN.1 parsing of "BINARY BLOB 4". + + 0 472: SEQUENCE { + 4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) + 15 457: [0] { + 19 453: SEQUENCE { + 23 1: INTEGER 1 + 26 11: SET { + 28 9: SEQUENCE { + 30 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) + 37 0: NULL + : } + : } + 39 11: SEQUENCE { + 41 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) + : } + 52 420: SET { + 56 416: SEQUENCE { + 60 1: INTEGER 1 + 63 125: SEQUENCE { + 65 112: SEQUENCE { + 67 11: SET { + 69 9: SEQUENCE { + 71 3: OBJECT IDENTIFIER countryName (2 5 4 6) + 76 2: PrintableString 'US' + : } + : } + 80 19: SET { + 82 17: SEQUENCE { + 84 3: OBJECT IDENTIFIER + : stateOrProvinceName (2 5 4 8) + 89 10: UTF8String 'California' + : } + : } + 101 17: SET { + 103 15: SEQUENCE { + 105 3: OBJECT IDENTIFIER localityName (2 5 4 7) + 110 8: UTF8String 'San Jose' + : } + : } + 120 14: SET { + 122 12: SEQUENCE { + 124 3: OBJECT IDENTIFIER + : organizationName (2 5 4 10) + 129 5: UTF8String 'sipit' + : } + : } + 136 41: SET { + + + +Jennings, et al. Informational [Page 26] + +RFC 6216 SIP Secure Call Flows April 2011 + + + 138 39: SEQUENCE { + 140 3: OBJECT IDENTIFIER + : organizationalUnitName (2 5 4 11) + 145 32: UTF8String 'Sipit Test Certificate + Authority' + : } + : } + : } + 179 9: INTEGER 00 96 A3 84 17 4E EF 8A 4D + : } + 190 9: SEQUENCE { + 192 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) + 199 0: NULL + : } + 201 13: SEQUENCE { + 203 9: OBJECT IDENTIFIER + : rsaEncryption (1 2 840 113549 1 1 1) + 214 0: NULL + : } + 216 256: OCTET STRING + : 6E 51 AC 24 2E BA 7C A1 EE 80 A8 55 BC D4 64 5D + : E5 29 09 5F B2 AF AA 6F 91 D2 97 79 32 5B AF CA + : FE A1 73 FC E5 57 4E C6 3B 67 35 AA E4 78 1E 59 + : 93 EE 67 63 77 1E 7A 82 BC 1E 26 0F 39 75 0C A6 + : 26 92 01 6A B7 5D F0 C0 2C 51 46 FB A7 36 44 E3 + : 64 C6 11 CB 0B 6B FD F3 6D 7C FD 3E AE 2E 91 BB + : 78 9E F4 1B A1 20 68 B9 DE D3 E3 0C FC F7 14 9A + : 2C 64 AB 27 52 BD 52 EC 27 88 14 BD DB C3 54 C7 + : EA 48 DB 07 E9 9B 2E C8 BE 62 A2 76 83 53 37 E8 + : 02 4B D1 86 E9 DF 2E BD 93 39 EC 2F 01 53 A0 7F + : 1A B9 A6 31 FC E7 91 1C DB 22 4A 67 83 94 B2 4E + : 28 A9 CD DE 4A 04 6A E0 86 90 7B 58 5F DB 7A 96 + : 96 A0 25 61 C2 58 A2 28 E5 B3 B2 F1 6D 51 06 9C + : 78 61 0D D8 3A A7 9F A3 B5 87 0B 80 11 C2 A9 1A + : E5 17 1C EB 82 55 AB CD 04 E7 D9 5B 11 E8 B7 47 + : FE FD CC B7 DB 47 6F 77 85 9E 24 D8 11 E1 E4 7D + : } + : } + : } + : } + : } + +5. Observed Interoperability Issues + + This section describes some common interoperability problems. These + were observed by the authors at SIPit interoperability events. + Implementers should be careful to verify that their systems do not + introduce these common problems, and, when possible, make their + + + +Jennings, et al. Informational [Page 27] + +RFC 6216 SIP Secure Call Flows April 2011 + + + clients forgiving in what they receive. Implementations should take + extra care to produce reasonable error messages when interacting with + software that has these problems. + + Some SIP clients incorrectly only do SSLv3 and do not support TLS. + See Section 26.2.1 of [RFC3261]. + + Many SIP clients were found to accept expired certificates with no + warning or error. See Section 4.1.2.5 of [RFC5280]. + + When used with SIP, TLS and S/MIME provide the identity of the peer + that a client is communicating with in the Subject Alternative Name + in the certificate. The software checks that this name corresponds + to the identity the server is trying to contact. Normative text + describing path validation can be found in Section 7 of [RFC5922] and + Section 6 of [RFC5280]. If a client is trying to set up a TLS + connection to good.example.com and it gets a TLS connection set up + with a server that presents a valid certificate but with the name + evil.example.com, it will typically generate an error or warning of + some type. Similarly with S/MIME, if a user is trying to communicate + with sip:fluffy@example.com, one of the items in the Subject + Alternate Name set in the certificate will need to match according to + the certificate validation rules in Section 23 of [RFC3261] and + Section 6 of [RFC5280]. + + Some implementations used binary MIME encodings while others used + base64. It is advisable that implementations send only binary and + are prepared to receive either. See Section 3.2 of [RFC5621]. + + In several places in this document, the messages contain the encoding + for the SHA-1 digest algorithm identifier. The preferred form for + encoding as set out in Section 2 of [RFC3370] is the form in which + the optional AlgorithmIdentifier parameter field is omitted. + However, [RFC3370] also says the recipients need to be able to + receive the form in which the AlgorithmIdentifier parameter field is + present and set to NULL. Examples of the form using NULL can be + found in Section 4.2 of [RFC4134]. Receivers really do need to be + able to receive the form that includes the NULL because the NULL + form, while not preferred, is what was observed as being generated by + most implementations. Implementers should also note that if the + algorithm is MD5 instead of SHA-1, then the form that omits the + AlgorithmIdentifier parameters field is not allowed and the sender + has to use the form where the NULL is included. + + The preferred encryption algorithm for S/MIME in SIP is AES as + defined in [RFC3853]. + + + + + +Jennings, et al. Informational [Page 28] + +RFC 6216 SIP Secure Call Flows April 2011 + + + Observed S/MIME interoperability has been better when UAs did not + attach the senders' certificates. Attaching the certificates + significantly increases the size of the messages, which should be + considered when sending over UDP. Furthermore, the receiver cannot + rely on the sender to always send the certificate, so it does not + turn out to be useful in most situations. + + Please note that the certificate path validation algorithm described + in Section 6 of [RFC5280] is a complex algorithm for which all of the + details matter. There are numerous ways in which failing to + precisely implement the algorithm as specified in Section 6 of + [RFC5280] can create a security flaw, a simple example of which is + the failure to check the expiration date that is already mentioned + above. It is important for developers to ensure that this validation + is performed and that the results are verified by their applications + or any libraries that they use. + +6. Additional Test Scenarios + + This section provides a non-exhaustive list of tests that + implementations should perform while developing systems that use + S/MIME and TLS for SIP. + + Much of the required behavior for inspecting certificates when using + S/MIME and TLS with SIP is currently underspecified. The non- + normative recommendations in this document capture the current + folklore around that required behavior, guided by both related + normative works such as [RFC4474] (particularly, Section 13.4 Domain + Names and Subordination) and informative works such as [RFC2818], + Section 3.1. To summarize, test plans should: + + o For S/MIME secured bodies, ensure that the peer's URI (address-of- + record, as per [RFC3261], Section 23.3) appears in the + subjectAltName of the peer's certificate as a + uniformResourceIdentifier field. + + o For TLS, ensure that the peer's hostname appears as described in + [RFC5922]. Also: + + * ensure an exact match in a dNSName entry in the subjectAltName + if there are any dNSNames in the subjectAltName. Wildcard + matching is not allowed against these dNSName entries. See + Section 7.1 of [RFC5922]. + + * ensure that the most specific CommonName in the Subject field + matches if there are no dNSName entries in the subjectAltName + at all (which is not the same as there being no matching + + + + +Jennings, et al. Informational [Page 29] + +RFC 6216 SIP Secure Call Flows April 2011 + + + dNSName entries). This match can be either exact, or against + an entry that uses the wildcard matching character '*'. + + The peer's hostname is discovered from the initial DNS query in + the server location process [RFC3263]. + + o IP addresses can appear in subjectAltName ([RFC5280]) of the + peer's certificate, e.g., "IP:192.168.0.1". Note that if IP + addresses are used in subjectAltName, there are important + ramifications regarding the use of Record-Route headers that also + need to be considered. See Section 7.5 of [RFC5922]. Use of IP + addresses instead of domain names is inadvisable. + + For each of these tests, an implementation will proceed past the + verification point only if the certificate is "good". S/MIME + protected requests presenting bad certificate data will be rejected. + S/MIME protected responses presenting bad certificate information + will be ignored. TLS connections involving bad certificate data will + not be completed. + + 1. S/MIME : Good peer certificate + + 2. S/MIME : Bad peer certificate (peer URI does not appear in + subjectAltName) + + 3. S/MIME : Bad peer certificate (valid authority chain does not + end at a trusted CA) + + 4. S/MIME : Bad peer certificate (incomplete authority chain) + + 5. S/MIME : Bad peer certificate (the current time does not fall + within the period of validity) + + 6. S/MIME : Bad peer certificate (certificate, or certificate in + authority chain, has been revoked) + + 7. S/MIME : Bad peer certificate ("Digital Signature" is not + specified as an X509v3 Key Usage) + + 8. TLS : Good peer certificate (hostname appears in dNSName in + subjectAltName) + + 9. TLS : Good peer certificate (no dNSNames in subjectAltName, + hostname appears in Common Name (CN) of Subject) + + + + + + + +Jennings, et al. Informational [Page 30] + +RFC 6216 SIP Secure Call Flows April 2011 + + + 10. TLS : Good peer certificate (CN of Subject empty, and + subjectAltName extension contains an iPAddress stored in the + octet string in network byte order form as specified in RFC 791 + [RFC0791]) + + 11. TLS : Bad peer certificate (no match in dNSNames or in the + Subject CN) + + 12. TLS : Bad peer certificate (valid authority chain does not end + at a trusted CA) + + 13. TLS : Bad peer certificate (incomplete authority chain) + + 14. TLS : Bad peer certificate (the current time does not fall + within the period of validity) + + 15. TLS : Bad peer certificate (certificate, or certificate in + authority chain, has been revoked) + + 16. TLS : Bad peer certificate ("TLS Web Server Authentication" is + not specified as an X509v3 Key Usage) + + 17. TLS : Bad peer certificate (Neither "SIP Domain" nor "Any + Extended Key Usage" specified as an X509v3 Extended Key Usage, + and X509v3 Extended Key Usage is present) + +7. Acknowledgments + + Many thanks to the developers of all the open source software used to + create these call flows. This includes the underlying crypto and TLS + software used from openssl.org, the SIP stack from + www.resiprocate.org, and the SIP for Instant Messaging and Presence + Leveraging Extensions (SIMPLE) Instant Messaging and Presence + Protocol (IMPP) agent from www.sipimp.org. The TLS flow dumps were + done with SSLDump from http://www.rtfm.com/ssldump. The book "SSL + and TLS" [EKR-TLS] was a huge help in developing the code for these + flows. It's sad there is no second edition. + + Thanks to Jim Schaad, Russ Housley, Eric Rescorla, Dan Wing, Tat + Chan, and Lyndsay Campbell, who all helped find and correct mistakes + in this document. + + Vijay Gurbani and Alan Jeffrey contributed much of the additional + test scenario content. + + + + + + + +Jennings, et al. Informational [Page 31] + +RFC 6216 SIP Secure Call Flows April 2011 + + +8. Security Considerations + + Implementers must never use any of the certificates provided in this + document in anything but a test environment. Installing the CA root + certificates used in this document as a trusted root in operational + software would completely destroy the security of the system while + giving the user the impression that the system was operating + securely. + + This document recommends some things that implementers might test or + verify to improve the security of their implementations. It is + impossible to make a comprehensive list of these, and this document + only suggests some of the most common mistakes that have been seen at + the SIPit interoperability events. Just because an implementation + does everything this document recommends does not make it secure. + + This document does not show any messages to check certificate + revocation status (see Sections 3.3 and 6.3 of [RFC5280]) as that is + not part of the SIP call flow. The expectation is that revocation + status is checked regularly to protect against the possibility of + certificate compromise or repudiation. For more information on how + certificate revocation status can be checked, see [RFC2560] (Online + Certificate Status Protocol) and [RFC5055] (Server-Based Certificate + Validation Protocol). + +9. References + +9.1. Normative References + + [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., + and C. Adams, "X.509 Internet Public Key + Infrastructure Online Certificate Status Protocol + - OCSP", RFC 2560, June 1999. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., + Johnston, A., Peterson, J., Sparks, R., Handley, + M., and E. Schooler, "SIP: Session Initiation + Protocol", RFC 3261, June 2002. + + [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session + Initiation Protocol (SIP): Locating SIP Servers", + RFC 3263, June 2002. + + [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) + Algorithms", RFC 3370, August 2002. + + + +Jennings, et al. Informational [Page 32] + +RFC 6216 SIP Secure Call Flows April 2011 + + + [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., + Huitema, C., and D. Gurle, "Session Initiation + Protocol (SIP) Extension for Instant Messaging", + RFC 3428, December 2002. + + [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard + (AES) Requirement for the Session Initiation + Protocol (SIP)", RFC 3853, July 2004. + + [RFC4474] Peterson, J. and C. Jennings, "Enhancements for + Authenticated Identity Management in the Session + Initiation Protocol (SIP)", RFC 4474, August 2006. + + [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., + and W. Polk, "Server-Based Certificate Validation + Protocol (SCVP)", RFC 5055, December 2007. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer + Security (TLS) Protocol Version 1.2", RFC 5246, + August 2008. + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, + S., Housley, R., and W. Polk, "Internet X.509 + Public Key Infrastructure Certificate and + Certificate Revocation List (CRL) Profile", + RFC 5280, May 2008. + + [RFC5621] Camarillo, G., "Message Body Handling in the + Session Initiation Protocol (SIP)", RFC 5621, + September 2009. + + [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", + STD 70, RFC 5652, September 2009. + + [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose + Internet Mail Extensions (S/MIME) Version 3.2 + Message Specification", RFC 5751, January 2010. + + [RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain + Certificates in the Session Initiation Protocol + (SIP)", RFC 5922, June 2010. + + [RFC5923] Gurbani, V., Mahy, R., and B. Tate, "Connection + Reuse in the Session Initiation Protocol (SIP)", + RFC 5923, June 2010. + + + + + + +Jennings, et al. Informational [Page 33] + +RFC 6216 SIP Secure Call Flows April 2011 + + + [RFC5924] Lawrence, S. and V. Gurbani, "Extended Key Usage + (EKU) for Session Initiation Protocol (SIP) X.509 + Certificates", RFC 5924, June 2010. + + [X.509] International Telecommunications Union, + "Information technology - Open Systems + Interconnection - The Directory: Public-key and + attribute certificate frameworks", + ITU-T Recommendation X.509 (2005), ISO/ + IEC 9594-8:2005. + + [X.683] International Telecommunications Union, + "Information technology - Abstract Syntax Notation + One (ASN.1): Parameterization of ASN.1 + specifications", ITU-T Recommendation X.683 + (2002), ISO/IEC 8824-4:2002, 2002. + +9.2. Informative References + + [EKR-TLS] Rescorla, E., "SSL and TLS - Designing and + Building Secure Systems", Addison-Wesley, ISBN + 0-201-61598-3, 2001. + + [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. + + [RFC4134] Hoffman, P., "Examples of S/MIME Messages", + RFC 4134, July 2005. + + [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., + Rosenberg, J., and H. Schulzrinne, "Session + Initiation Protocol (SIP) Torture Test Messages", + RFC 4475, May 2006. + + [RFC4514] Zeilenga, K., "Lightweight Directory Access + Protocol (LDAP): String Representation of + Distinguished Names", RFC 4514, June 2006. + + [ssldump-manpage] Rescorla, E., "SSLDump manpage", + . + + + + + + + + + + + + +Jennings, et al. Informational [Page 34] + +RFC 6216 SIP Secure Call Flows April 2011 + + +Appendix A. Making Test Certificates + + These scripts allow you to make certificates for test purposes. The + certificates will all share a common CA root so that everyone running + these scripts can have interoperable certificates. WARNING - these + certificates are totally insecure and are for test purposes only. + All the CAs created by this script share the same private key to + facilitate interoperability testing, but this totally breaks the + security since the private key of the CA is well known. + + The instructions assume a Unix-like environment with openssl + installed, but openssl does work in Windows too. OpenSSL version + 0.9.8j was used to generate the certificates used in this document. + Make sure you have openssl installed by trying to run "openssl". Run + the makeCA script found in Appendix A.1; this creates a subdirectory + called demoCA. If the makeCA script cannot find where your openssl + is installed you will have to set an environment variable called + OPENSSLDIR to whatever directory contains the file openssl.cnf. You + can find this with a "locate openssl.cnf". You are now ready to make + certificates. + + To create certificates for use with TLS, run the makeCert script + found in Appendix A.2 with the fully qualified domain name of the + proxy you are making the certificate for, e.g., "makeCert + host.example.net domain eku". This will generate a private key and a + certificate. The private key will be left in a file named + domain_key_example.net.pem in Privacy Enhanced Mail (PEM) format. + The certificate will be in domain_cert_example.net.pem. Some + programs expect both the certificate and private key combined + together in a Public-Key Cryptography Standards (PKCS) #12 format + file. This is created by the script and left in a file named + example.net.p12. Some programs expect this file to have a .pfx + extension instead of .p12 -- just rename the file if needed. A file + with a certificate signing request, called example.net.csr, is also + created and can be used to get the certificate signed by another CA. + + A second argument indicating the number of days for which the + certificate should be valid can be passed to the makeCert script. It + is possible to make an expired certificate using the command + "makeCert host.example.net 0". + + Anywhere that a password is used to protect a certificate, the + password is set to the string "password". + + The root certificate for the CA is in the file + root_cert_fluffyCA.pem. + + + + + +Jennings, et al. Informational [Page 35] + +RFC 6216 SIP Secure Call Flows April 2011 + + + For things that need DER format certificates, a certificate can be + converted from PEM to DER with "openssl x509 -in cert.pem -inform PEM + -out cert.der -outform DER". + + Some programs expect certificates in PKCS #7 format (with a file + extension of .p7c). You can convert these from PEM format to PKCS #7 + with "openssl crl2pkcs7 -nocrl -certfile cert.pem -certfile demoCA/ + cacert.pem -outform DER -out cert.p7c". + + IE (version 8), Outlook Express (version 6), and Firefox (version + 3.5) can import and export .p12 files and .p7c files. You can + convert a PKCS #7 certificate to PEM format with "openssl pkcs7 -in + cert.p7c -inform DER -outform PEM -out cert.pem". + + The private key can be converted to PKCS #8 format with "openssl + pkcs8 -in a_key.pem -topk8 -outform DER -out a_key.p8c". + + In general, a TLS client will just need the root certificate of the + CA. A TLS server will need its private key and its certificate. + These could be in two PEM files, a single file with both certificate + and private key PEM sections, or a single .p12 file. An S/MIME + program will need its private key and certificate, the root + certificate of the CA, and the certificate for every other user it + communicates with. + +A.1. makeCA script + + #!/bin/sh + set -x + + rm -rf demoCA + + mkdir demoCA + mkdir demoCA/certs + mkdir demoCA/crl + mkdir demoCA/newcerts + mkdir demoCA/private + # This is done to generate the exact serial number used for the RFC + echo "4902110184015C" > demoCA/serial + touch demoCA/index.txt + + # You may need to modify this for where your default file is + # you can find where yours in by typing "openssl ca" + for D in /etc/ssl /usr/local/ssl /sw/etc/ssl /sw/share/ssl; do + CONF=${OPENSSLDIR:=$D}/openssl.cnf + [ -f ${CONF} ] && break + done + + + + +Jennings, et al. Informational [Page 36] + +RFC 6216 SIP Secure Call Flows April 2011 + + + CONF=${OPENSSLDIR}/openssl.cnf + + + if [ ! -f $CONF ]; then + echo "Can not find file $CONF - set your OPENSSLDIR variable" + exit + fi + + cp $CONF openssl.cnf + + cat >> openssl.cnf < demoCA/private/cakey.pem < demoCA/cacert.pem < demoCA/serial + echo 96a384174eef8a4d > demoCA/serial + + + + +Jennings, et al. Informational [Page 39] + +RFC 6216 SIP Secure Call Flows April 2011 + + + openssl crl2pkcs7 -nocrl -certfile demoCA/cacert.pem \ + -outform DER -out demoCA/cacert.p7c + + cp demoCA/cacert.pem root_cert_fluffyCA.pem + +A.2. makeCert script + + #!/bin/sh + set -x + + # Make a symbolic link to this file called "makeUserCert" + # if you wish to use it to make certs for users. + + # ExecName=$(basename $0) + # + # if [ ${ExecName} == "makeUserCert" ]; then + # ExtPrefix="sipuser" + # elif [ ${ExecName} == "makeEkuUserCert" ]; then + # ExtPrefix="sipuser_eku" + # elif [ ${ExecName} == "makeEkuCert" ]; then + # ExtPrefix="sipdomain_eku" + # else + # ExtPrefix="sipdomain" + # fi + + + if [ $# == 3 ]; then + DAYS=36500 + elif [ $# == 4 ]; then + DAYS=$4 + else + echo "Usage: makeCert test.example.org user|domain eku|noeku [days]" + echo " makeCert alice@example.org [days]" + echo "days is how long the certificate is valid" + echo "days set to 0 generates an invalid certificate" + exit 0 + fi + + ExtPrefix="sip"${2} + + if [ $3 == "noeku" ]; then + ExtPrefix=${ExtPrefix}"_noeku" + fi + + DOMAIN=`echo $1 | perl -ne '{print "$1\n" if (/(\w+\..*)$/)}' ` + USER=`echo $1 | perl -ne '{print "$1\n" if (/(\w+)\@(\w+\..*)$/)}' ` + ADDR=$1 + echo "making cert for $DOMAIN ${ADDR}" + + + +Jennings, et al. Informational [Page 40] + +RFC 6216 SIP Secure Call Flows April 2011 + + + if [ $2 == "user" ]; then + CNVALUE=$USER + else + CNVALUE=$DOMAIN + fi + + rm -f ${ADDR}_*.pem + rm -f ${ADDR}.p12 + + case ${ADDR} in + *:*) ALTNAME="URI:${ADDR}" ;; + *@*) ALTNAME="URI:sip:${ADDR},URI:im:${ADDR},URI:pres:${ADDR}" ;; + *) ALTNAME="DNS:${DOMAIN},URI:sip:${ADDR}" ;; + esac + + rm -f demoCA/index.txt + touch demoCA/index.txt + rm -f demoCA/newcerts/* + + export ALTNAME + + openssl genrsa -out ${ADDR}_key.pem 2048 + openssl req -new -config openssl.cnf -reqexts ${ExtPrefix}_req \ + -sha1 -key ${ADDR}_key.pem \ + -out ${ADDR}.csr -days ${DAYS} <