\section{S/MIME}
\label{sec:security:smime}

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~\citenorm{rfc1847}, RFC~2630~\citenorm{rfc2630} and 
RFC~2633~\citenorm{rfc2633}).  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.  \motivation{This applies particularly to certain types of
firewalls.}

\motivation{The PGP mechanism for encrypting the header fields and bodies of
SIP messages described in RFC~2543 has been deprecated.}

\subsection{S/MIME Certificates}
\label{sec:security:smime:certs}

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 ``\header{userinfo}'' ``@'' and
``\header{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. 

\begin{changebar}
These certificates are also associated with keys that are used to 
sign or encrypt bodies of SIP messages. 
\end{changebar}
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 \header{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~\ref{sec:security:limits:smime}.
\begin{changebar}
Implementations may also use pre-configured certificates in 
deployments in which a previous trust relationship exists between
all SIP entities.
\end{changebar}

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.

\subsection{S/MIME Key Exchange}
\label{sec:security:smime: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. 
\begin{changebar}
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.
\end{changebar}

\begin{changebar}
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 \header{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 \header{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.  
\end{changebar}
If the certificate was successfully verified and the
subject of the certificate corresponds to the \header{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.  

\begin{changebar}
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.  
\end{changebar}
The UAC
{\SHOULD} also determine the subject of the certificate and compare this
value to the \header{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 \header{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 \header{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.  
\begin{changebar}
If the user authorizes this certificate, it
{\SHOULD} be added to the keyring alongside any previous value(s) for this
address-of-record.
\end{changebar}

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~\ref{sec:security:limits:smime}.

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 \header{To} header field of the rejected
request) within a 
MIME body with a `certs-only' ``\header{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 \header{Content-Disposition} header 
``\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;
\begin{changebar}
however, this 415 response may constitute a downgrade attack.
\end{changebar}

\begin{changebar}
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 {\SHOULDNOT} 
respond with a secured body, but if it expects S/MIME from the 
sender (for example, because the sender's \header{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.
\end{changebar}

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.

\subsection{Securing MIME bodies}
\label{sec:security:encrypt}

There are two types of secure MIME bodies that are of interest to SIP: 
'multipart/signed' and 'application/pkcs7-mime'.  The procedures for the
use of these bodies should follow the S/MIME specification~\citenorm{rfc2633}
with a few variations.

\begin{itemize}

\item ``multipart/signed'' {\MUST} be used only with CMS detached
signatures.

\motivation{This allows backwards compatibility with
non-S/MIME-compliant recipients.}

 
\item S/MIME bodies {\SHOULD} have a \header{Content-Disposition}
header field, and the value of the
``\header{handling}'' parameter {\SHOULD} be ``required.''


\item 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~\ref{sec:security:tunnel}).

\begin{changebar}
\motivation{Note that future standardization work on S/MIME may define
non-certificate based keys.}
\end{changebar}

\item Senders of S/MIME bodies {\SHOULD} use the ``SMIMECapabilities''
(see Section~2.5.2 of~\citenorm{rfc2633}) 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).

\item 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.

\item 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.
\begin{changebar}
Parallel signatures {\SHOULDNOT} be used.
\end{changebar}


\begin{changebar}
The following is an example of an encrypted S/MIME SDP body within a 
SIP message:

\begin{verbatim}
        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-Transfer-Encoding: base64
        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                                *
      *******************************************************
\end{verbatim}
\end{changebar}


\end{itemize}

\subsection{SIP Header Privacy and Integrity using S/MIME: Tunneling SIP}
\label{sec:security:tunnel}

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.

\subsubsection{Integrity and Confidentiality Properties of SIP Headers}
\label{sec:security:tunnel: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.

\begin{changebar}
Note that for the purposes of loose timestamping, all SIP messages that
tunnel ``message/sip'' {\SHOULD} contain a \header{Date} header in both 
the ``inner'' and ``outer'' headers. 
\end{changebar}

\paragraph{Integrity}

\begin{changebar}
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~\ref{sec:header-fields}.
\end{changebar}

Header fields that can be legitimately modified by proxy servers are: 
\header{Request-URI}, \header{Via}, \header{Record-Route}, \header{Route}, 
\header{Max-Forwards}, and \header{Proxy-Authorization}. If these header fields
are not intact end-to-end, implementations {\SHOULDNOT} consider this a 
breach of security. Changes to any other header fields
\begin{changebar}
defined in this document
\end{changebar}
constitute an integrity 
violation; users {\MUST} be notified of a discrepancy.

\paragraph{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: \header{To}, 
\header{From}, \header{Call-ID}, \header{CSeq}, \header{Contact}. While 
it is probably not useful to provide an encrypted alternative for the 
\header{Call-ID}, \header{Cseq}, or \header{Contact}, providing an 
alternative to the information in the ``outer'' \header{To} or 
\header{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 \header{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 {\MUSTNOT} 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: \header{Subject}, \header{Reply-To}, 
\header{Organization}, \header{Accept}, \header{Accept-Encoding}, 
\header{Accept-Language}, \header{Alert-Info}, \header{Error-Info}, 
\header{Authentication-Info}, \header{Expires}, \header{In-Reply-To}, 
\header{Require}, \header{Supported}, \header{Unsupported}, 
\header{Retry-After}, \header{User-Agent}, \header{Server}, and 
\header{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. 
\begin{changebar}
They {\SHOULDNOT} however be used in the ``outer'' 
headers of any future messages.

If present, the \header{Date} header field {\MUST} always be the same in 
the ``inner'' and ``outer'' headers.
\end{changebar}

Since MIME bodies are attached to the ``inner'' message, 
implementations will usually encrypt MIME-specific header fields, 
including: \header{MIME-Version}, \header{Content-Type}, 
\header{Content-Length}, \header{Content-Language}, 
\header{Content-Encoding} and \header{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: 
\header{Min-Expires}, 
\header{Timestamp}, \header{Authorization}, \header{Priority}, and 
\header{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.

\subsubsection{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 (\header{To}, \header{From}, \header{Call-ID},
\header{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. 
\begin{changebar}
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.
\end{changebar}

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.

\begin{changebar}
If a \header{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.
\end{changebar}

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:

\begin{verbatim}
     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-
\end{verbatim}

\subsubsection{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 \header{Subject} or \header{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 \header{From} header
field that contains no personal information (for example,
sip:anonymous@anonymizer.invalid).  However, a second \header{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.

\begin{changebar}
motivation{Note that if this mechanism is used for anonymity, the 
\header{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'' \header{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:

\begin{verbatim}
     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-
\end{verbatim}
\end{changebar}
