Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6216

Example Call Flows Using Session Initiation Protocol (SIP) Security Mechanisms

Pages: 67
Informational
Part 1 of 3 – Pages 1 to 14
None   None   Next

Top   ToC   RFC6216 - Page 1
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.
Top   ToC   RFC6216 - Page 2
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
Top   ToC   RFC6216 - Page 3

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.
Top   ToC   RFC6216 - Page 4

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
Top   ToC   RFC6216 - Page 5
       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
Top   ToC   RFC6216 - Page 6
 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
Top   ToC   RFC6216 - Page 7
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
Top   ToC   RFC6216 - Page 8
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:
Top   ToC   RFC6216 - Page 9
               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
Top   ToC   RFC6216 - Page 10
   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:
Top   ToC   RFC6216 - Page 11
               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
Top   ToC   RFC6216 - Page 12

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
Top   ToC   RFC6216 - Page 13
           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 <allOneLine> convention from [RFC4475] is used to break long lines. The actual message does not contain the line breaks contained within those tags.
Top   ToC   RFC6216 - Page 14
   MESSAGE sips:kumiko@example.net:5061 SIP/2.0
   <allOneLine>
   Via: SIP/2.0/TLS 192.0.2.2:15001;
        branch=z9hG4bK-d8754z-c785a077a9a8451b-1---d8754z-;
        rport=50738
   </allOneLine>
   Max-Forwards: 70
   To: <sips:kumiko@example.net:5061>
   From: <sips:fluffy@example.com:15001>;tag=1a93430b
   Call-ID: OTZmMDE2OWNlYTVjNDkzYzBhMWRlMDU4NDExZmU4ZTQ.
   CSeq: 4308 MESSAGE
   <allOneLine>
   Accept: multipart/signed, text/plain, application/pkcs7-mime,
           application/sdp, multipart/alternative
   </allOneLine>
   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
   <allOneLine>
   Via: SIP/2.0/TLS 192.0.2.2:15001;
        branch=z9hG4bK-d8754z-c785a077a9a8451b-1---d8754z-;
        rport=50738
   </allOneLine>
   To: <sips:kumiko@example.net:5061>;tag=0d075510
   From: <sips:fluffy@example.com:15001>;tag=1a93430b
   Call-ID: OTZmMDE2OWNlYTVjNDkzYzBhMWRlMDU4NDExZmU4ZTQ.
   CSeq: 4308 MESSAGE
   Content-Length: 0


(next page on part 2)

Next Section