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.

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

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.

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

       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

 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

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

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:

               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

   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:

               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

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

           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.

   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