tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6216

 
 
 

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

Part 2 of 3, p. 15 to 34
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 15 
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
   <allOneLine>
   Via: SIP/2.0/TCP 192.0.2.2:15001;
        branch=z9hG4bK-d8754z-3a922b6dc0f0ff37-1---d8754z-;
        rport=50739
   </allOneLine>
   Max-Forwards: 70
   To: <sip:kumiko@example.net>
   From: <sip:fluffy@example.com>;tag=ef6bad5e
   Call-ID: N2NiZjI0NjRjNDQ0MTY1NDRjNWNmMGU1MDA2MDRhYmI.
   CSeq: 8473 MESSAGE
   <allOneLine>
   Accept: multipart/signed, text/plain, application/pkcs7-mime,
           application/sdp, multipart/alternative
   </allOneLine>
   <allOneLine>
   Content-Type: multipart/signed;boundary=3b515e121b43a911;
                 micalg=sha1;protocol="application/pkcs7-signature"
   </allOneLine>
   Content-Length: 774

   --3b515e121b43a911
   Content-Type: text/plain
   Content-Transfer-Encoding: binary

   Hello!
   --3b515e121b43a911
   Content-Type: application/pkcs7-signature;name=smime.p7s
   <allOneLine>
   Content-Disposition: attachment;handling=required;
                        filename=smime.p7s
   </allOneLine>
   Content-Transfer-Encoding: binary

   *****************
   * BINARY BLOB 1 *
   *****************
   --3b515e121b43a911--

Top      Up      ToC       Page 16 
   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'

Top      Up      ToC       Page 17 
          :                   }
          :                 }
    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

Top      Up      ToC       Page 18 
          :             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 {

Top      Up      ToC       Page 19 
    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

Top      Up      ToC       Page 20 
          :           }
          :         }
          :       }
          :     }
          :   }

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
   <allOneLine>
   Via: SIP/2.0/TCP 192.0.2.2:15001;
        branch=z9hG4bK-d8754z-c276232b541dd527-1---d8754z-;
        rport=50741
   </allOneLine>
   Max-Forwards: 70
   To: <sip:kumiko@example.net>
   From: <sip:fluffy@example.com>;tag=7a2e3025
   Call-ID: MDYyMDhhODA3NWE2ZjEyYzAwOTZlMjExNWI2ZWQwZGM.
   CSeq: 3260 MESSAGE
   <allOneLine>
   Accept: multipart/signed, text/plain, application/pkcs7-mime,
           application/sdp, multipart/alternative
   </allOneLine>
   <allOneLine>
   Content-Disposition: attachment;handling=required;
                        filename=smime.p7
   </allOneLine>
   Content-Transfer-Encoding: binary
   <allOneLine>
   Content-Type: application/pkcs7-mime;smime-type=enveloped-data;
                 name=smime.p7m
   </allOneLine>
   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] {

Top      Up      ToC       Page 21 
   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

Top      Up      ToC       Page 22 
          :             }
    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
   <allOneLine> 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

Top      Up      ToC       Page 23 
   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
   <allOneLine>
   Via: SIP/2.0/TCP 192.0.2.2:15001;
        branch=z9hG4bK-d8754z-97a26e59b7262b34-1---d8754z-;
        rport=50742
   </allOneLine>
   Max-Forwards: 70
   To: <sip:kumiko@example.net>
   From: <sip:fluffy@example.com>;tag=379f5b27
   Call-ID: MjYwMzdjYTY3YWRkYzgzMjU0MGI4Mzc2Njk1YzJlNzE.
   CSeq: 5449 MESSAGE
   <allOneLine>
   Accept: multipart/signed, text/plain, application/pkcs7-mime,
           application/sdp, multipart/alternative
   </allOneLine>
   <allOneLine>
   Content-Type: multipart/signed;boundary=e8df6e1ce5d1e864;
                 micalg=sha1;protocol="application/pkcs7-signature"
   </allOneLine>
   Content-Length: 1455

   --e8df6e1ce5d1e864
   <allOneLine>
   Content-Type: application/pkcs7-mime;smime-type=enveloped-data;
                 name=smime.p7m
   </allOneLine>
   <allOneLine>
   Content-Disposition: attachment;handling=required;
                        filename=smime.p7
   </allOneLine>
   Content-Transfer-Encoding: binary

   *****************
   * BINARY BLOB 3 *
   *****************
   --e8df6e1ce5d1e864
   Content-Type: application/pkcs7-signature;name=smime.p7s
   <allOneLine>
   Content-Disposition: attachment;handling=required;
                        filename=smime.p7s
   </allOneLine>
   Content-Transfer-Encoding: binary

   *****************
   * BINARY BLOB 4 *

Top      Up      ToC       Page 24 
   *****************
   --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'
          :                   }

Top      Up      ToC       Page 25 
          :                 }
          :               }
    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
          :         }
          :       }
          :     }
          :   }

Top      Up      ToC       Page 26 
   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 {

Top      Up      ToC       Page 27 
    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

Top      Up      ToC       Page 28 
   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].

Top      Up      ToC       Page 29 
   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

Top      Up      ToC       Page 30 
         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)

Top      Up      ToC       Page 31 
   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.

Top      Up      ToC       Page 32 
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.

Top      Up      ToC       Page 33 
   [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.

Top      Up      ToC       Page 34 
   [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",
                      <http://www.rtfm.com/ssldump/Ssldump.html>.


Next RFC Part