Section 23 S/MIME

SIP messages carry MIME bodies and the MIME standard includes
   mechanisms for securing MIME contents to ensure both integrity and
   confidentiality (including the 'multipart/signed' and
   'application/pkcs7-mime' MIME types, see RFC 1847 [22], RFC 2630 [23]
   and RFC 2633 [24]).  Implementers should note, however, that there
   may be rare network intermediaries (not typical proxy servers) that
   rely on viewing or modifying the bodies of SIP messages (especially
   SDP), and that secure MIME may prevent these sorts of intermediaries
   from functioning.
      This applies particularly to certain types of firewalls.
      The PGP mechanism for encrypting the header fields and bodies of
      SIP messages described in RFC 2543 has been deprecated.
23.1 S/MIME Certificates
   The certificates that are used to identify an end-user for the
   purposes of S/MIME differ from those used by servers in one important
   respect - rather than asserting that the identity of the holder
   corresponds to a particular hostname, these certificates assert that
   the holder is identified by an end-user address.  This address is
   composed of the concatenation of the "userinfo" "@" and "domainname"
   portions of a SIP or SIPS URI (in other words, an email address of
   the form "bob@biloxi.com"), most commonly corresponding to a user's
   address-of-record.
   These certificates are also associated with keys that are used to
   sign or encrypt bodies of SIP messages.  Bodies are signed with the
   private key of the sender (who may include their public key with the
   message as appropriate), but bodies are encrypted with the public key
   of the intended recipient.  Obviously, senders must have
   foreknowledge of the public key of recipients in order to encrypt
   message bodies.  Public keys can be stored within a UA on a virtual
   keyring.
   Each user agent that supports S/MIME MUST contain a keyring
   specifically for end-users' certificates.  This keyring should map
   between addresses of record and corresponding certificates.  Over
   time, users SHOULD use the same certificate when they populate the
   originating URI of signaling (the From header field) with the same
   address-of-record.
   Any mechanisms depending on the existence of end-user certificates
   are seriously limited in that there is virtually no consolidated
   authority today that provides certificates for end-user applications.
   However, users SHOULD acquire certificates from known public
   certificate authorities.  As an alternative, users MAY create self-
   signed certificates.  The implications of self-signed certificates
   are explored further in Section 26.4.2.  Implementations may also use
   pre-configured certificates in deployments in which a previous trust
   relationship exists between all SIP entities.
   Above and beyond the problem of acquiring an end-user certificate,
   there are few well-known centralized directories that distribute
   end-user certificates.  However, the holder of a certificate SHOULD
   publish their certificate in any public directories as appropriate.
   Similarly, UACs SHOULD support a mechanism for importing (manually or
   automatically) certificates discovered in public directories
   corresponding to the target URIs of SIP requests.
23.2 S/MIME Key Exchange
   SIP itself can also be used as a means to distribute public keys in
   the following manner.
   Whenever the CMS SignedData message is used in S/MIME for SIP, it
   MUST contain the certificate bearing the public key necessary to
   verify the signature.
   When a UAC sends a request containing an S/MIME body that initiates a
   dialog, or sends a non-INVITE request outside the context of a
   dialog, the UAC SHOULD structure the body as an S/MIME
   'multipart/signed' CMS SignedData body.  If the desired CMS service
   is EnvelopedData (and the public key of the target user is known),
   the UAC SHOULD send the EnvelopedData message encapsulated within a
   SignedData message.
   When a UAS receives a request containing an S/MIME CMS body that
   includes a certificate, the UAS SHOULD first validate the
   certificate, if possible, with any available root certificates for
   certificate authorities.  The UAS SHOULD also determine the subject
   of the certificate (for S/MIME, the SubjectAltName will contain the
   appropriate identity) and compare this value to the From header field
   of the request.  If the certificate cannot be verified, because it is
   self-signed, or signed by no known authority, or if it is verifiable
   but its subject does not correspond to the From header field of
   request, the UAS MUST notify its user of the status of the
   certificate (including the subject of the certificate, its signer,
   and any key fingerprint information) and request explicit permission
   before proceeding.  If the certificate was successfully verified and
   the subject of the certificate corresponds to the From header field
   of the SIP request, or if the user (after notification) explicitly
   authorizes the use of the certificate, the UAS SHOULD add this
   certificate to a local keyring, indexed by the address-of-record of
   the holder of the certificate.
   When a UAS sends a response containing an S/MIME body that answers
   the first request in a dialog, or a response to a non-INVITE request
   outside the context of a dialog, the UAS SHOULD structure the body as
   an S/MIME 'multipart/signed' CMS SignedData body.  If the desired CMS
   service is EnvelopedData, the UAS SHOULD send the EnvelopedData
   message encapsulated within a SignedData message.
   When a UAC receives a response containing an S/MIME CMS body that
   includes a certificate, the UAC SHOULD first validate the
   certificate, if possible, with any appropriate root certificate.  The
   UAC SHOULD also determine the subject of the certificate and compare
   this value to the To field of the response; although the two may very
   well be different, and this is not necessarily indicative of a
   security breach.  If the certificate cannot be verified because it is
   self-signed, or signed by no known authority, the UAC MUST notify its
   user of the status of the certificate (including the subject of the
   certificate, its signator, and any key fingerprint information) and
   request explicit permission before proceeding.  If the certificate
   was successfully verified, and the subject of the certificate
   corresponds to the To header field in the response, or if the user
   (after notification) explicitly authorizes the use of the
   certificate, the UAC SHOULD add this certificate to a local keyring,
   indexed by the address-of-record of the holder of the certificate.
   If the UAC had not transmitted its own certificate to the UAS in any
   previous transaction, it SHOULD use a CMS SignedData body for its
   next request or response.
   On future occasions, when the UA receives requests or responses that
   contain a From header field corresponding to a value in its keyring,
   the UA SHOULD compare the certificate offered in these messages with
   the existing certificate in its keyring.  If there is a discrepancy,
   the UA MUST notify its user of a change of the certificate
   (preferably in terms that indicate that this is a potential security
   breach) and acquire the user's permission before continuing to
   process the signaling.  If the user authorizes this certificate, it
   SHOULD be added to the keyring alongside any previous value(s) for
   this address-of-record.
   Note well however, that this key exchange mechanism does not
   guarantee the secure exchange of keys when self-signed certificates,
   or certificates signed by an obscure authority, are used - it is
   vulnerable to well-known attacks.  In the opinion of the authors,
   however, the security it provides is proverbially better than
   nothing; it is in fact comparable to the widely used SSH application.
   These limitations are explored in greater detail in Section 26.4.2.
   If a UA receives an S/MIME body that has been encrypted with a public
   key unknown to the recipient, it MUST reject the request with a 493
   (Undecipherable) response.  This response SHOULD contain a valid
   certificate for the respondent (corresponding, if possible, to any
   address of record given in the To header field of the rejected
   request) within a MIME body with a 'certs-only' "smime-type"
   parameter.
   A 493 (Undecipherable) sent without any certificate indicates that
   the respondent cannot or will not utilize S/MIME encrypted messages,
   though they may still support S/MIME signatures.
   Note that a user agent that receives a request containing an S/MIME
   body that is not optional (with a Content-Disposition header
   "handling" parameter of "required") MUST reject the request with a
   415 Unsupported Media Type response if the MIME type is not
   understood.  A user agent that receives such a response when S/MIME
   is sent SHOULD notify its user that the remote device does not
   support S/MIME, and it MAY subsequently resend the request without
   S/MIME, if appropriate; however, this 415 response may constitute a
   downgrade attack.
   If a user agent sends an S/MIME body in a request, but receives a
   response that contains a MIME body that is not secured, the UAC
   SHOULD notify its user that the session could not be secured.
   However, if a user agent that supports S/MIME receives a request with
   an unsecured body, it SHOULD NOT respond with a secured body, but if
   it expects S/MIME from the sender (for example, because the sender's
   From header field value corresponds to an identity on its keychain),
   the UAS SHOULD notify its user that the session could not be secured.
   A number of conditions that arise in the previous text call for the
   notification of the user when an anomalous certificate-management
   event occurs.  Users might well ask what they should do under these
   circumstances.  First and foremost, an unexpected change in a
   certificate, or an absence of security when security is expected, are
   causes for caution but not necessarily indications that an attack is
   in progress.  Users might abort any connection attempt or refuse a
   connection request they have received; in telephony parlance, they
   could hang up and call back.  Users may wish to find an alternate
   means to contact the other party and confirm that their key has
   legitimately changed.  Note that users are sometimes compelled to
   change their certificates, for example when they suspect that the
   secrecy of their private key has been compromised.  When their
   private key is no longer private, users must legitimately generate a
   new key and re-establish trust with any users that held their old
   key.
   Finally, if during the course of a dialog a UA receives a certificate
   in a CMS SignedData message that does not correspond with the
   certificates previously exchanged during a dialog, the UA MUST notify
   its user of the change, preferably in terms that indicate that this
   is a potential security breach.
23.3 Securing MIME bodies
   There are two types of secure MIME bodies that are of interest to
   SIP: use of these bodies should follow the S/MIME specification [24]
   with a few variations.
      o  "multipart/signed" MUST be used only with CMS detached
         signatures.
            This allows backwards compatibility with non-S/MIME-
            compliant recipients.
      o  S/MIME bodies SHOULD have a Content-Disposition header field,
         and the value of the "handling" parameter SHOULD be "required."
      o  If a UAC has no certificate on its keyring associated with the
         address-of-record to which it wants to send a request, it
         cannot send an encrypted "application/pkcs7-mime" MIME message.
         UACs MAY send an initial request such as an OPTIONS message
         with a CMS detached signature in order to solicit the
         certificate of the remote side (the signature SHOULD be over a
         "message/sip" body of the type described in Section 23.4).
            Note that future standardization work on S/MIME may define
            non-certificate based keys.
      o  Senders of S/MIME bodies SHOULD use the "SMIMECapabilities"
         (see Section 2.5.2 of [24]) attribute to express their
         capabilities and preferences for further communications.  Note
         especially that senders MAY use the "preferSignedData"
         capability to encourage receivers to respond with CMS
         SignedData messages (for example, when sending an OPTIONS
         request as described above).
      o  S/MIME implementations MUST at a minimum support SHA1 as a
         digital signature algorithm, and 3DES as an encryption
         algorithm.  All other signature and encryption algorithms MAY
         be supported.  Implementations can negotiate support for these
         algorithms with the "SMIMECapabilities" attribute.
      o  Each S/MIME body in a SIP message SHOULD be signed with only
         one certificate.  If a UA receives a message with multiple
         signatures, the outermost signature should be treated as the
         single certificate for this body.  Parallel signatures SHOULD
         NOT be used.
         The following is an example of an encrypted S/MIME SDP body
         within a SIP message:
        INVITE sip:bob@biloxi.com SIP/2.0
        Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
        To: Bob <sip:bob@biloxi.com>
        From: Alice <sip:alice@atlanta.com>;tag=1928301774
        Call-ID: a84b4c76e66710
        CSeq: 314159 INVITE
        Max-Forwards: 70
        Contact: <sip:alice@pc33.atlanta.com>
        Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
             name=smime.p7m
        Content-Disposition: attachment; filename=smime.p7m
           handling=required
      *******************************************************
      * Content-Type: application/sdp                       *
      *                                                     *
      * v=0                                                 *
      * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com *
      * s=-                                                 *
      * t=0 0                                               *
      * c=IN IP4 pc33.atlanta.com                           *
      * m=audio 3456 RTP/AVP 0 1 3 99                       *
      * a=rtpmap:0 PCMU/8000                                *
      *******************************************************
23.4 SIP Header Privacy and Integrity using S/MIME: Tunneling SIP
   As a means of providing some degree of end-to-end authentication,
   integrity or confidentiality for SIP header fields, S/MIME can
   encapsulate entire SIP messages within MIME bodies of type
   "message/sip" and then apply MIME security to these bodies in the
   same manner as typical SIP bodies.  These encapsulated SIP requests
   and responses do not constitute a separate dialog or transaction,
   they are a copy of the "outer" message that is used to verify
   integrity or to supply additional information.
   If a UAS receives a request that contains a tunneled "message/sip"
   S/MIME body, it SHOULD include a tunneled "message/sip" body in the
   response with the same smime-type.
   Any traditional MIME bodies (such as SDP) SHOULD be attached to the
   "inner" message so that they can also benefit from S/MIME security.
   Note that "message/sip" bodies can be sent as a part of a MIME
   "multipart/mixed" body if any unsecured MIME types should also be
   transmitted in a request.
23.4.1 Integrity and Confidentiality Properties of SIP Headers
   When the S/MIME integrity or confidentiality mechanisms are used,
   there may be discrepancies between the values in the "inner" message
   and values in the "outer" message.  The rules for handling any such
   differences for all of the header fields described in this document
   are given in this section.
   Note that for the purposes of loose timestamping, all SIP messages
   that tunnel "message/sip" SHOULD contain a Date header in both the
   "inner" and "outer" headers.
23.4.1.1 Integrity
   Whenever integrity checks are performed, the integrity of a header
   field should be determined by matching the value of the header field
   in the signed body with that in the "outer" messages using the
   comparison rules of SIP as described in 20.
   Header fields that can be legitimately modified by proxy servers are:
   Request-URI, Via, Record-Route, Route, Max-Forwards, and Proxy-
   Authorization.  If these header fields are not intact end-to-end,
   implementations SHOULD NOT consider this a breach of security.
   Changes to any other header fields defined in this document
   constitute an integrity violation; users MUST be notified of a
   discrepancy.
23.4.1.2 Confidentiality
   When messages are encrypted, header fields may be included in the
   encrypted body that are not present in the "outer" message.
   Some header fields must always have a plaintext version because they
   are required header fields in requests and responses - these include:
   To, From, Call-ID, CSeq, Contact.  While it is probably not useful to
   provide an encrypted alternative for the Call-ID, CSeq, or Contact,
   providing an alternative to the information in the "outer" To or From
   is permitted.  Note that the values in an encrypted body are not used
   for the purposes of identifying transactions or dialogs - they are
   merely informational.  If the From header field in an encrypted body
   differs from the value in the "outer" message, the value within the
   encrypted body SHOULD be displayed to the user, but MUST NOT be used
   in the "outer" header fields of any future messages.
   Primarily, a user agent will want to encrypt header fields that have
   an end-to-end semantic, including: Subject, Reply-To, Organization,
   Accept, Accept-Encoding, Accept-Language, Alert-Info, Error-Info,
   Authentication-Info, Expires, In-Reply-To, Require, Supported,
   Unsupported, Retry-After, User-Agent, Server, and Warning.  If any of
   these header fields are present in an encrypted body, they should be
   used instead of any "outer" header fields, whether this entails
   displaying the header field values to users or setting internal
   states in the UA.  They SHOULD NOT however be used in the "outer"
   headers of any future messages.
   If present, the Date header field MUST always be the same in the
   "inner" and "outer" headers.
   Since MIME bodies are attached to the "inner" message,
   implementations will usually encrypt MIME-specific header fields,
   including: MIME-Version, Content-Type, Content-Length, Content-
   Language, Content-Encoding and Content-Disposition.  The "outer"
   message will have the proper MIME header fields for S/MIME bodies.
   These header fields (and any MIME bodies they preface) should be
   treated as normal MIME header fields and bodies received in a SIP
   message.
   It is not particularly useful to encrypt the following header fields:
   Min-Expires, Timestamp, Authorization, Priority, and WWW-
   Authenticate.  This category also includes those header fields that
   can be changed by proxy servers (described in the preceding section).
   UAs SHOULD never include these in an "inner" message if they are not
   included in the "outer" message.  UAs that receive any of these
   header fields in an encrypted body SHOULD ignore the encrypted
   values.
   Note that extensions to SIP may define additional header fields; the
   authors of these extensions should describe the integrity and
   confidentiality properties of such header fields.  If a SIP UA
   encounters an unknown header field with an integrity violation, it
   MUST ignore the header field.
23.4.2 Tunneling Integrity and Authentication
   Tunneling SIP messages within S/MIME bodies can provide integrity for
   SIP header fields if the header fields that the sender wishes to
   secure are replicated in a "message/sip" MIME body signed with a CMS
   detached signature.
   Provided that the "message/sip" body contains at least the
   fundamental dialog identifiers (To, From, Call-ID, CSeq), then a
   signed MIME body can provide limited authentication.  At the very
   least, if the certificate used to sign the body is unknown to the
   recipient and cannot be verified, the signature can be used to
   ascertain that a later request in a dialog was transmitted by the
   same certificate-holder that initiated the dialog.  If the recipient
   of the signed MIME body has some stronger incentive to trust the
   certificate (they were able to validate it, they acquired it from a
   trusted repository, or they have used it frequently) then the
   signature can be taken as a stronger assertion of the identity of the
   subject of the certificate.
   In order to eliminate possible confusions about the addition or
   subtraction of entire header fields, senders SHOULD replicate all
   header fields from the request within the signed body.  Any message
   bodies that require integrity protection MUST be attached to the
   "inner" message.
   If a Date header is present in a message with a signed body, the
   recipient SHOULD compare the header field value with its own internal
   clock, if applicable.  If a significant time discrepancy is detected
   (on the order of an hour or more), the user agent SHOULD alert the
   user to the anomaly, and note that it is a potential security breach.
   If an integrity violation in a message is detected by its recipient,
   the message MAY be rejected with a 403 (Forbidden) response if it is
   a request, or any existing dialog MAY be terminated.  UAs SHOULD
   notify users of this circumstance and request explicit guidance on
   how to proceed.
   The following is an example of the use of a tunneled "message/sip"
   body:
      INVITE sip:bob@biloxi.com SIP/2.0
      Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
      To: Bob <sip:bob@biloxi.com>
      From: Alice <sip:alice@atlanta.com>;tag=1928301774
      Call-ID: a84b4c76e66710
      CSeq: 314159 INVITE
      Max-Forwards: 70
      Date: Thu, 21 Feb 2002 13:02:03 GMT
      Contact: <sip:alice@pc33.atlanta.com>
      Content-Type: multipart/signed;
        protocol="application/pkcs7-signature";
        micalg=sha1; boundary=boundary42
      Content-Length: 568
      --boundary42
      Content-Type: message/sip
      INVITE sip:bob@biloxi.com SIP/2.0
      Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
      To: Bob <bob@biloxi.com>
      From: Alice <alice@atlanta.com>;tag=1928301774
      Call-ID: a84b4c76e66710
      CSeq: 314159 INVITE
      Max-Forwards: 70
      Date: Thu, 21 Feb 2002 13:02:03 GMT
      Contact: <sip:alice@pc33.atlanta.com>
      Content-Type: application/sdp
      Content-Length: 147
      v=0
      o=UserA 2890844526 2890844526 IN IP4 here.com
      s=Session SDP
      c=IN IP4 pc33.atlanta.com
      t=0 0
      m=audio 49172 RTP/AVP 0
      a=rtpmap:0 PCMU/8000
      --boundary42
      Content-Type: application/pkcs7-signature; name=smime.p7s
      Content-Transfer-Encoding: base64
      Content-Disposition: attachment; filename=smime.p7s;
         handling=required
      ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
      4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
      n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
      7GhIGfHfYT64VQbnj756
      --boundary42-
23.4.3 Tunneling Encryption
   It may also be desirable to use this mechanism to encrypt a
   "message/sip" MIME body within a CMS EnvelopedData message S/MIME
   body, but in practice, most header fields are of at least some use to
   the network; the general use of encryption with S/MIME is to secure
   message bodies like SDP rather than message headers.  Some
   informational header fields, such as the Subject or Organization
   could perhaps warrant end-to-end security.  Headers defined by future
   SIP applications might also require obfuscation.
   Another possible application of encrypting header fields is selective
   anonymity.  A request could be constructed with a From header field
   that contains no personal information (for example,
   sip:anonymous@anonymizer.invalid).  However, a second From header
   field containing the genuine address-of-record of the originator
   could be encrypted within a "message/sip" MIME body where it will
   only be visible to the endpoints of a dialog.
      Note that if this mechanism is used for anonymity, the From header
      field will no longer be usable by the recipient of a message as an
      index to their certificate keychain for retrieving the proper
      S/MIME key to associated with the sender.  The message must first
      be decrypted, and the "inner" From header field MUST be used as an
      index.
   In order to provide end-to-end integrity, encrypted "message/sip"
   MIME bodies SHOULD be signed by the sender.  This creates a
   "multipart/signed" MIME body that contains an encrypted body and a
   signature, both of type "application/pkcs7-mime".
   In the following example, of an encrypted and signed message, the
   text boxed in asterisks ("*") is encrypted:
        INVITE sip:bob@biloxi.com SIP/2.0
        Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
        To: Bob <sip:bob@biloxi.com>
        From: Anonymous <sip:anonymous@atlanta.com>;tag=1928301774
        Call-ID: a84b4c76e66710
        CSeq: 314159 INVITE
        Max-Forwards: 70
        Date: Thu, 21 Feb 2002 13:02:03 GMT
        Contact: <sip:pc33.atlanta.com>
        Content-Type: multipart/signed;
          protocol="application/pkcs7-signature";
          micalg=sha1; boundary=boundary42
        Content-Length: 568
        --boundary42
        Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
             name=smime.p7m
        Content-Transfer-Encoding: base64
        Content-Disposition: attachment; filename=smime.p7m
           handling=required
        Content-Length: 231
      ***********************************************************
      * Content-Type: message/sip                               *
      *                                                         *
      * INVITE sip:bob@biloxi.com SIP/2.0                       *
      * Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 *
      * To: Bob <bob@biloxi.com>                                *
      * From: Alice <alice@atlanta.com>;tag=1928301774          *
      * Call-ID: a84b4c76e66710                                 *
      * CSeq: 314159 INVITE                                     *
      * Max-Forwards: 70                                        *
      * Date: Thu, 21 Feb 2002 13:02:03 GMT                     *
      * Contact: <sip:alice@pc33.atlanta.com>                   *
      *                                                         *
      * Content-Type: application/sdp                           *
      *                                                         *
      * v=0                                                     *
      * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com     *
      * s=Session SDP                                           *
      * t=0 0                                                   *
      * c=IN IP4 pc33.atlanta.com                               *
      * m=audio 3456 RTP/AVP 0 1 3 99                           *
      * a=rtpmap:0 PCMU/8000                                    *
      ***********************************************************
        --boundary42
        Content-Type: application/pkcs7-signature; name=smime.p7s
        Content-Transfer-Encoding: base64
        Content-Disposition: attachment; filename=smime.p7s;
           handling=required
        ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
        4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
        n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
        7GhIGfHfYT64VQbnj756
        --boundary42-