[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                                MMUSIC WG
Internet Draft                                               P. Kirstein
draft-ietf-mmusic-sip-sec-00.txt                    G. Montasser-Kohsari
March 12th 1998                                                E. Whelan
Expires: September 12th 1998                   University College London


                 SIP Security Using Public Key Algorithms


                         STATUS OF THIS MEMO

  This document is an Internet-Draft. Internet-Drafts are working
  documents of the Internet Engineering Task Force (IETF), its areas,
  and its working groups. Note that other groups may also distribute
  working documents as Internet-Drafts.

  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any
  time. It is inappropriate to use Internet-Drafts as reference material
  or to cite them other than as ``work in progress.''

  To learn the current status of any Internet-Draft, please check the
  ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  Directories  on  ftp.is.co.za (Africa), ftp.nordu.net (Europe),
  munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  ftp.isi.edu (US West Coast).

  Distribution of this document is unlimited.


                               ABSTRACT

  The Session Initiation Protocol (SIP) is a simple protocol designed
  to enable the invitation of users to multimedia sessions. This
  document is a companion draft to draft-ietf-mmusic-sip-04.txt, which
  defines SIP but doesn't specify any security mechanisms other than
  possible protection by lower-level security mechanisms such as SSL.
  This leaves SIP transactions vulnerable to attack and this document
  aims to extend the SIP protocol to address such security
  considerations.  This document is a product of the Multiparty
  Multimedia Session Control (MMUSIC) working group of the Internet
  Engineering Task Force Comments are solicited and should be addressed
  to the working group's mailing list at confctrl@isi.edu and/or the
  authors.












Kirstein et al.                                                [PAGE  1]

Internet Draft                SIP Security                March 12, 1998



                          TABLE OF CONTENTS



  1. Introduction ..................................................  3
    1.1 Overview of SIP Functionality ..............................  3
    1.2 Terminology ................................................  3
    1.3 SIP Message Overview .......................................  3
      1.3.1 Request ................................................  4
      1.3.2 Response ...............................................  4
      1.3.3 SIP Version ............................................  5
    1.4 SIP Transaction ............................................  5
      1.4.1 Example of a SIP Invitation ............................  5
    1.5 Transport-Protocol .........................................  7
  2. Security Considerations .......................................  7
    2.1 Symmetric and Asymmetric Encryption ........................  8
  3. SIP Security With PGP and MIME ................................  9
    3.1 PGP Data Formats ...........................................  9
    3.2 MIME Encapsulation .........................................  9
    3.3 PGP Encrypted Data ......................................... 10
    3.4 PGP Signed Data ............................................ 12
    3.5 PGP Encrypted and Signed Data .............................. 13
      3.5.1 RFC 1847 Encapsulation ................................. 13
      3.5.2 Combined Encryption and Signing ........................ 15
    3.6 PGP Supported Algorithms ................................... 15
  4. SIP Security with S/MIME ...................................... 15
    4.1 The application/pkcs7-mime Type ............................ 16
    4.2 Encryption Only with S/MIME ................................ 16
    4.3 Signing Only with S/MIME ................................... 16
      4.3.1 Signing Using application/pkcs7-mime and SignedData .... 17
      4.3.2 Signing Using the multipart/signed Format .............. 17
    4.4 Signing and Encrypting ..................................... 19
    4.5 S/MIME Supported Algorithms ................................ 19

  References ....................................................... 21
  Authors' Addresses ............................................... 24
  Acknowledgements ................................................. 24
















Kirstein et al.                                                [PAGE  2]

Internet Draft                SIP Security                March 12, 1998

1. Introduction

1.1 Overview of SIP Functionality

  The Session Initiation Protocol (SIP) is an application-layer protocol
  that can establish and control multimedia sessions or calls.  These
  multimedia sessions include multimedia conferences, distance learning,
  Internet telephony and similar applications. SIP can invite a person
  to both unicast and multicast sessions; the initiator does not
  necessarily have to be a member of the session it is inviting to.
  Media and participants can be added to an existing session. SIP can be
  used to "call" both persons and "robots", for example, to invite a
  media storage device to record an ongoing conference or to invite a
  video-on-demand server to play a video into a conference. SIP can be
  used to initiate sessions as well as invite members to sessions that
  have been advertised and established by other means such as SAP [1],
  electronic mail, news groups, web pages and directories (LDAP). SIP is
  fully defined in [2] and, as this is a companion draft aiming to
  extend the basic functionality of SIP to address security
  considerations, familiarity with [2] is assumed. Consequently, only a
  brief introduction to SIP itself is included here.

1.2 Terminology

  In this document, the key words "MUST", "MUST NOT", "REQUIRED",
  "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
  and "OPTIONAL" are to be interpreted as described in RFC 2119 [28]
  and indicate requirement levels for compliant SIP implementations.

1.3 SIP Message Overview

  As much of the message syntax is identical to HTTP/1.1 the notation
  [HX.Y] is used to refer to section X.Y of the current HTTP/1.1 [16]
  specification. In addition an augmented Backus-Naur form (BNF) [17]
  [H2.1] is used. All SIP messages are text-based and use HTTP/1.1
  conventions [H4.1], except for the additional ability of SIP to use
  UDP. When sent over TCP or UDP, multiple SIP transactions can be
  carried in a single TCP connection or UDP datagram. UDP datagrams,
  including all headers, should not normally be larger than the path
  maximum transmission unit (MTU) if the MTU is known or 1500 bytes if
  the MTU is unknown. The 1400 bytes accommodates lower-layer packet
  headers within the "typical" MTU of around 1500 bytes. There are few
  MTU values around 1 kB; the next value is 1006 bytes for SLIP and 296
  for low-delay PPP [18]. Recent studies [19] indicate that an MTU of
  1500 bytes is a reasonable assumption. Thus, another reasonable value
  would be a message size of 950 bytes, to accommodate packet headers
  within the SLIP MTU without fragmentation.

  A SIP message is either a request from a client to a server, or a
  response from a server to a client.

        SIP-message  =  Request | Response ; SIP messages



Kirstein et al.                                                [PAGE  3]

Internet Draft                SIP Security                March 12, 1998

  Both Request and Response messages use the generic RFC822 [3] message
  format for transferring entities (the payload of the message). Both
  types of message consist of a start-line, one or more header fields,
  an empty line indicating the end of the header fields and an optional
  message body.

   Generic message = start-line
                     *(general header | request header | entity header)
                     CRLF
                     [message body]

        start-line = Request Line | Status Line

1.3.1 Request

  The Request message format is shown below:

           Request = Request Line
                     *(general header | request header | entity header)
                     CRLF
                     [message body]

  The Request Line begins with a method token, followed by the
  Request-URI, the protocol version and ending with a CRLF. SP
  characters separate each element.

       Request Line = Method SP Request-URI SP SIP-Version CRLF

            Method  = "INVITE" | "ACK" | "OPTIONS" |
                      "BYE" | "REGISTER" | "UNREGISTER"

  INVITE indicates that the user or service is being invited to
  participate and the message body contains a description of the
  relevant session. ACK confirms that the client has received a final
  response to an INVITE request. OPTIONS is used to query a client
  about its capabilities. The client uses BYE to indicate to the server
  that it wishes to abort the call attempt. REGISTER is used by the
  client to register the address listed in the request line to a SIP
  server and UNREGISTER is used to cancel an existing registration.
  Support for INVITE and ACK is mandatory in the SIP specification
  whereas support for OPTIONS, BYE, REGISTER and UNREGISTER is OPTIONAL.

1.3.2 Response

  Once a recipient has received and interpreted a request message they
  respond with a SIP response message. The format of the response is
  shown below:

          Response = Status Line
                     *(general header | request header | entity header)
                     CRLF
                     [message body]

  The Status Line is similar to the Request Line. It consists of the SIP

Kirstein et al.                                                [PAGE  4]

Internet Draft                SIP Security                March 12, 1998

  Version, a numeric Status Code and its associated textual phrase. SP
  characters separate each element and the line ends with a CRLF
  sequence.

      Status Line = SIP Version SP Status Code SP Reason Phrase CRLF

1.3.3 SIP Version

  Both request and response messages include the version of SIP in use
  and this follows [H3.1], with HTTP replaced by SIP. Applications
  making use of the security enhancements detailed in this paper MUST
  include a SIP-Version of "SIP/2.1".

1.4 SIP Transaction

  When making a SIP call a caller first locates the appropriate sever
  and then sends a SIP request. The most common SIP operation is the
  invitation. Instead of directly reaching the intended callee, a SIP
  request may be redirected or trigger a new chain of requests by
  proxies.

1.4.1 Example of a SIP Invitation

  A successful SIP invitation consists of two requests, INVITE followed
  by ACK. The INVITE request asks the callee to join a particular
  conference or establish a two-party conversation. After the callee has
  agreed to participate in the call, the caller confirms that it has
  received that response by sending an ACK request. If the call is
  rejected, or otherwise unsuccessful, the caller sends a BYE request
  instead of an ACK.

  The INVITE request typically contains a session description, for
  example written in SDP format [4], that provides the called party with
  enough in formation to join the session. For multicast sessions, the
  session description enumerates the media types and formats that may be
  distributed to that session. For unicast sessions, the session
  description enumerates the media types and formats that the caller is
  willing to receive and where it wishes the media data to be sent. In
  either case, if the callee wishes to accept the call, it responds to
  the invitation by returning a similar description listing the media it
  wishes to receive. For a multicast session, the callee should only
  return a session description if it is unable to receive the media
  indicated in the caller's description. The caller may ignore the
  session description returned or use it to change the global session
  description.

  The protocol exchanges for the INVITE method are shown in Fig. 1 for a
  proxy server and in Fig. 2 for a redirect server. The proxy server
  accepts the INVITE request (1), contacts the location service with all
  or parts of the address (2) and obtains a more precise location (3).
  The proxy server then issues a SIP INVITE request to the address(es)
  returned by the location service (4). The user agent server alerts the
  user (5) and returns a success indication to the proxy server (6). The
  proxy server then returns the success result to the original caller

Kirstein et al.                                                [PAGE  5]

Internet Draft                SIP Security                March 12, 1998

  (7). The receipt of this message is confirmed by the caller using an
  ACK message, which is forwarded to the callee (8,9), with a response
  returned (10,11). All requests have the same Call-ID.

                                            +....... cs.columbia.edu .......+
                                            :                               :
                                            : (~~~~~~~~~~)                  :
                                            : ( location )                  :
                                            : ( service  )                  :
                                            : (~~~~~~~~~~)                  :
                                            :   ^      |                    :
                                            :   |   hgs@play                :
                                            :  2|     3|                    :
                                            :   |      |                    :
                                            : henning  |                    :
   +.. cs.tu-berlin.de ..+ 1: INVITE        :   |      |                    :
   :                     :    henning@cs.col:   |      | 4: INVITE  5: ring :
   : cz@cs.tu-berlin.de ========================> tune  =========> play     :
   :                    <........................       <.........          :
   :                     : 7: 200 OK        :            6: 200 OK          :
   +.....................+                  +...............................+

   ====> SIP request
   ----> non-SIP protocols

   Figure 1: Example of SIP proxy server


  The redirect server accepts the INVITE request (1), contacts the
  location service as before (2,3) and, instead of contacting the newly
  found address itself, returns the address to the caller (4). The
  caller issues a new request, with a new call-ID, to the address
  returned by the first server (6). In the example, the call succeeds
  (7). The caller and callee complete the handshake with an ACK (8,9).

  The action taken on receiving a list of locations varies with the type
  of SIP server. A SIP redirect server simply returns the list to the
  client sending the request as Location headers. A SIP proxy server can
  sequentially or in parallel try the addresses.

  If a proxy server forwards a SIP request, it MUST add itself to the
  end of the list of forwarders noted in the Via headers. The Via trace
  ensures that replies can take the same path back, thus ensuring
  correct operation through compliant firewalls and loop-free requests.
  On the reply path, each host most remove its Via, so that routing
  internal information is hidden from the callee and outside networks.
  When a multicast request is made, first the host making the request,
  then the multicast address itself are added to the path. A proxy
  server MUST check that it does not generate a request to a host listed
  in the Via list. (Note: If a host has several names or network
  addresses, this may not always work. Thus, each host also checks if it
  is part of the Via list.)



Kirstein et al.                                                [PAGE  6]

Internet Draft                SIP Security                March 12, 1998

                                            +....... cs.columbia.edu .......+
                                            :                               :
                                            : (~~~~~~~~~~)                  :
                                            : ( location )                  :
                                            : ( service  )                  :
                                            : (~~~~~~~~~~)                  :
                                            :   ^      |                    :
                                            :   |   hgs@play                :
                                            :  2|     3|                    :
                                            :   |      |                    :
                                            : henning  |                    :
   +.. cs.tu-berlin.de ..+ 1: INVITE        :   |      |                    :
   :                     :    henning@cs.col:   |      |                    :
   : cz@cs.tu-berlin.de =======================>  tune                      :
   :         ^ |        <.......................                            :
   :         . |         : 4: 302 Moved     :                               :
   +...........|.........+    hgs@play      :                               :
             . |                            :                               :
             . | 5: INVITE hgs@play.cs.columbia.edu                6: ring  :
             . ==================================================> play     :
             .....................................................          :
               7: 200 OK                    :                               :
                                            +...............................+

   ====> SIP request
   ----> non-SIP protocols

  Figure 2: Example of SIP redirect server

1.5 Transport-Protocol

  SIP is able to utilise both UDP and TCP as transport protocols. UDP
  allows the application to more carefully control the timing of
  messages and their retransmission, to perform parallel searches
  without requiring TCP connection state for each outstanding request,
  and to use multicast.  Routers can more readily snoop SIP UDP packets.
  TCP allows easier passage through existing firewalls, and given the
  similar protocol design, allows common servers for SIP, HTTP and the
  RTSP [5].

2. Security Considerations

  The basic SIP Draft [2] does not deal with security considerations
  other than to specify a reliance on lower-layer security mechanisms
  such as SSL [6] when this is required. However, a number of issues
  need to be addressed. These include the following:

    - Authentication and Integrity of the SIP Communications

     Here it is necessary, for example, to ensure that if a callee
     receives an invitation they can be confident that the invitation
     did indeed originate from the claimed initiator and has not been
     changed en route. SIP messages can also modify details of future
     conferences and so it would also be possible for a denial of

Kirstein et al.                                                [PAGE  7]

Internet Draft                SIP Security                March 12, 1998

     service attack to be successful if messages cannot be
     authenticated.

    - Confidentiality of Conference Details

     Here it is at least necessary to hide the details of the addresses
     and media formats used. However, some proxies need to read certain
     SIP header fields.

  In order to facilitate the widespread implementation and use of SIP
  security it was considered important to re-use existing security
  implementations as much as possible. As much of this document is
  concerned with security it should not be considered authoritative in
  this area until the process of peer review has been completed.

2.1  Symmetric and Asymmetric Encryption

  The simplest versions of encryption are symmetric ones; here the
  encryption key can be calculated from the decryption key and vice
  versa. In most cases the encryption key and decryption key are the
  same. This means that, if E{a,M} is the operation of encrypting the
  message M with the key a and algorithm E, then the decryption
  operation D{a, E{a, M}} reproduces the original message M. If several
  people know the key then symmetric encryption cannot be used for
  authentication.

  An alternative form of encryption is with the use of asymmetric
  algorithms (also known as Public Key algorithms). Here the key used
  for encryption is different to that used for decryption and it is not
  feasible to calculate one from the other. Consequently the encryption
  key can be made public and is known as the Public Key. Encrypting a
  message with the recipient's Public Key ensures confidentiality as
  only the recipient with the corresponding decryption key (known as the
  Private Key) can decrypt the message. Encrypting a message with the
  Private Key of the sender ensures authentication as only the sender
  could have sent the message whereas anybody having access to the
  Public Key can verify that it was indeed sent by the person holding
  the corresponding Private Key. Some Public Key algorithms (e.g.RSA[7])
  can be used for both digital signatures and encryption whereas others
  (e.g. DSA) can only be used for digital signatures.

  Most practical implementations of public key cryptography use a
  combination of symmetric and asymmetric algorithms. This is largely
  due to the fact that symmetric algorithms are generally much faster
  than asymmetric ones as well as the fact that public key cryptosystems
  are vulnerable to chosen-plaintext attacks. Consequently, the messages
  are generally secured using a symmetric algorithm and a different
  session key each time. This session key is then encrypted and
  distributed using public key algorithms.

  The two public key algorithm formats which we make use of in this
  document are PGP [8] and S/MIME [9]. These can be used for both
  encryption and authentication. As detailed later implementers MUST
  support PGP formats with support for S/MIME being OPTIONAL.

Kirstein et al.                                                [PAGE  8]

Internet Draft                SIP Security                March 12, 1998

3. SIP Security With PGP and MIME

  The method specified here to secure SIP with PGP and MIME draws on
  RFC 1847 [10] and RFC 2015 [11].

3.1 PGP Data Formats

  PGP can generate either ASCII armour [8] or 8-bit binary output when
  encrypting data,  generating a digital signature or extracting a
  public key. With SIP an 8-bit clear channel is available and so ASCII
  armour is not necessary. However, for interoperability issues
  receiving agents SHOULD support the receipt of both armoured and
  unarmoured data. Receiving and sending agents MUST support unarmoured
  data.

3.2 MIME Encapsulation

  Prior to any security procedures the SIP message MUST be converted
  into MIME canonical format. The procedure for creating a MIME entity
  is given in [20] where the reader is referred for fuller details than
  are provided here. As SIP messages are text-based the MIME
  canonicalization for the type text/plain should be followed. In brief
  the line ending must be the <CR><LF> sequence and the charset should
  be a registered charset [21]. The details are specified in [20] and
  the chosen charset SHOULD be named in the charset parameter so the
  receiving agent can unambiguously determine the charset used.

  As SIP has an 8-bit clear channel available then no transfer encoding
  is necessary. However this should be supported in order to
  interoperate more easily and allow messages created with mail tools
  etc to be used without change. If a multipart/signed entity is being
  used it SHOULD have transfer encoding applied so that it is
  represented as 7-bit text. This would allow the signature on the data
  to be identical if it had been sent via email or via SIP which
  enhances flexibility.

  An example of a MIME prepared SIP message, with no security
  enhancements added, follows:

    Content-Type: text/plain; charset=iso-8859-1
    Content-Transfer-Encoding: quoted-printable

    INVITE j.doe@acme.com SIP/2.1
    To: J.Doe <joe@acme.com>
    From: Michael Elkins <elkins@aero.org>
    Subject: Videoconference on security issues
    CALL-ID: 786598
    Content-Type: application/sdp

    v=0
    o=anybody 3098086191 3098086197 IN IP4 anycomputer.anywhere.com
    s=general conference
    i=This is a general conference
    e=A. Nyone <anyone@anywhere.com>

Kirstein et al.                                                [PAGE  9]

Internet Draft                SIP Security                March 12, 1998

    p=A. Nyone +44 171 123 4567
    c=IN IP4 239.255.140.52/15
    t=3098084400 3098091600
    a=tool:sdr v2.5a0
    a=type:test
    m=audio 19274 RTP/AVP 0
    c=IN IP4 239.255.140.52/15
    a=ptime:40


  Outside the MIME body the only SIP headers used are those dealing with
  routing information which the proxies need access to. These include
  the From, To and Call-ID fields. In addition, if any other fields such
  as Proxy-Authenticate or Proxy-Authorization are present in the SIP
  message these SHOULD also appear outside the MIME body if the SIP
  message is only signed and MUST be present when the message is
  encrypted. This allows sensitive fields such as the Subject field to
  be present only in the MIME body which, when encrypted, makes these
  unreadable by the proxies. The SIP-header Content-Type MUST NOT appear
  with the headers outside the MIME body as this header field name is
  used by MIME.

  A "MIME-Version" header field [20] is then appended to the top-level
  SIP headers and this must include the following text:

    MIME-Version: 1.0

  This indicates that the SIP Messages have been produced in accordance
  with [20]. Note that all header fields in this document follow the
  general syntactic rules defined in RFC 822 and in particular comments
  are allowed. This means that the following are equivalent.

    MIME-Version: 1.0
    MIME-Version: 1.0 (Generated by SIP Server 3.4)


3.3 PGP Encrypted Data


  PGP encrypted data is denoted by the "multipart/encrypted" content
  type, as in RFC 1847, and MUST have a protocol parameter value of
  "application/pgp-encrypted" including the quotes. The
  multipart/encrypted message MUST consist of exactly two parts. The
  first MIME body part MUST have a content-type of
  "application/pgp-encrypted" and contain the control information. The
  PGP message itself contains all the relevant control information so a
  message complying with this standard MUST contain a "Version: 1" field
  in this body. The second MIME body part MUST contain the actual
  encrypted data and be labelled "application/octet-stream". The PGP
  message is the complete, original SIP message converted into MIME
  canonical format as in Section 3.2 and encrypted with the recipient's
  public key. An example of an invitation where the payload of the SIP
  message is in SDP format and ASCII armour has been used follows:


Kirstein et al.                                               [PAGE  10]


Internet Draft                SIP Security                March 12, 1998

    INVITE j.doe@acme.com SIP/2.1
    From: John Smith <J.Smith@aa.org>
    To: J.Doe <joe@acme.com>
    Call-ID: 554565
    MIME-Version: 1.0
    Content-Type: multipart/encrypted; boundary=foo;
            protocol="application/pgp-encrypted"

    --foo
    Content-Type: application/pgp-encrypted
    Version: 1

    --foo
    Content-Type: application/octet-stream

    -----BEGIN PGP MESSAGE-----
    Version: 2.6.3i
    hIwDjHVjzUcPoL0BA/0TlaOlL9qyUoEqP+jvSBKZLkQD9vU14O4WWf9h0EPUnHwQ
    6f8r+9YaxPvU7a25Oct2QE2oOIr+smDr+Z/NKld58ueFqvNQ+kXac9vRAzv403vt
    YYrh4ug1eetpe8znskWHiJv+3LHQBsNyWwLwoC78rIM2KQomhNUC6nvD9BP03qYA
    AADXS6iYIRljShpEtc137hBhx4Q9sXAh2ki2OnEPom+q0Pqwy2C5SgZfHfotg9Pt
    3HWRSJ64Se0VN2SQl9jFZ0oAkKtY79sCvkyhRGIjteLlufNbGBbLnbghN7uUBQi/
    URhXSWybyVMc2NoQaivRQxyHcXvhs8/687qPG2tGParPro2dbk8HiUN88lcdUCuL
    +aD8qDllVhESVkdXfUHvL28fHhdM2ERaFCKQVOt9/7mnF3LB6SSbJKZuZJ+BYg/3
    zuBVqDZo49yfURsgZ/iU2HWMXUydYEvxOR8=
    =1I+h
    -----END PGP MESSAGE-----

    --foo--

  Upon receipt of a multipart/encrypted body part the following is done.
  The second body part is prepared for decryption according to the value
  of the protocol parameter The prepared body part is made available to
  the decryption process and this makes available the result of the
  decryption and the decrypted form of the encrypted body part. The SIP
  implementation then continues processing with the decrypted body part.
  The unencrypted headers outside the MIME body SHOULD be discarded to
  avoid unwanted additions apart from the Via headers, added by the
  intermediate proxies, which are needed for routing any replies.

  The specification of a new SEALED method whereby the entire contents
  of the SIP message, including the From, To and Call-ID fields, are
  encrypted with the public key of the server at the next hop was
  considered.  This has the advantage that all sensitive information is
  encrypted during transit from server to server but has the
  disadvantage that each server can gain access to the full conference
  details etc. This is clearly undesirable and the possibility of
  encrypting a message as above with the recipient's public key and then
  re-encrypting it with the public key of the server at the next hop
  would be more secure. This allows each server access only to the
  information needed. However, this gives rise to a considerable
  overhead in both message size and processing time and is considered to
  give minimal benefit. Traffic analysis could gain access to
  information similar to that contained in the From and To fields and

Kirstein et al.                                                [PAGE 11]


Internet Draft                SIP Security                March 12, 1998

  the other sensitive fields such as Subject are already encrypted with
  the method detailed above.

3.4 PGP Signed Data

  PGP signed messages are denoted by the "multipart/signed" content
  type as in RFC 1847 with a protocol parameter which MUST have a value
  of "application/pgp-signature". The "micalg" parameter MUST have a
  value of "pgp-<hash-symbol>" where <hash-symbol> identifies the
  message integrity check used to generate the signature. The currently
  defined values for <hash-symbol> are "md5" for the MD5 checksum and
  "sha1" for the SHA.1 algorithm.

  The multipart/signed message MUST consist of exactly two parts, with
  the first part containing the data to be signed, in MIME canonical
  format, including a set of appropriate content headers describing the
  data. The second body part MUST contain the PGP digital signature and
  MUST be labelled with a content-type of "application/pgp-signature".
  The message is created in the same way as above in that only the
  information relevant to the proxies is outside the PGP signed message.
  As described in [10], the digital signature MUST be calculated over
  both the data to be signed and the set of content headers belonging to
  the body part to be signed. Also the signature MUST be generated
  detatched from the signed data so that the process does not alter the
  signed data in any way.

  An example of a PGP signed SIP message would be:

    INVITE j.doe@acme.com SIP/2.1
    From: Michael Elkins <elkins@aero.org>
    To: Michael Elkins <elkins@aero.org>
    CALL-ID: 786598
    Mime-Version: 1.0
    Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5;
        protocol="application/pgp-signature"

    --bar
    > Content-Type: text/plain; charset=iso-8859-1
    > Content-Transfer-Encoding: quoted-printable
    >
    > INVITE j.doe@acme.com SIP/2.1
    > To: J.Doe <joe@acme.com>
    > From: Michael Elkins <elkins@aero.org>
    > Subject: Videoconference on security issues
    > CALL-ID: 786598
    >
    > Content-Type: application/sdp
    >
    > v=0
    > o=anybody 3098086191 3098086197 IN IP4 anycomputer.anywhere.com
    > s=general conference
    > i=This is a general conference
    > e=A. Nyone <anyone@anywhere.com>
    > p=A. Nyone +44 171 123 4567

Kirstein et al.                                                [PAGE 12]


Internet Draft                SIP Security                March 12, 1998

    > c=IN IP4 239.255.140.52/15
    > t=3098084400 3098091600
    > a=tool:sdr v2.5a0
    > a=type:test
    > m=audio 19274 RTP/AVP 0
    > c=IN IP4 239.255.140.52/15
    > a=ptime:40
    >
    --bar
    Content-Type: application/pgp-signature

    -----BEGIN PGP MESSAGE-----
    Version: 2.6.3i

    iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
    jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
    uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
    HOxEa44b+EI=
    =ndaj
    -----END PGP MESSAGE-----

    --bar--

  The ">"s in the previous example indicate the portion of the data over
  which the signature was calculated. Upon receipt of a signed message,
  an application MUST pass both the signed data and its associated
  content headers along with the PGP signature to the signature
  verification service.


3.5 PGP Encrypted and Signed Data

  With SIP messages it is often desirable to digitally sign and then
  encrypt the messages. There are two methods for accomplishing this
  [11]. The data can be both encrypted and then signed or can undergo a
  joint "encryption and signing" process. Sending agents MUST support
  the joint process. Receiving agents SHOULD support both types of
  encryption and signing.


3.5.1 RFC 1847 Encapsulation

  Here, the data (SIP Message) should first be signed as a
  multipart/signed body as before and then encrypted to form the final
  multipart/encrypted body as below.


    INVITE j.doe@acme.com SIP/2.1
    From: John Smith <J.Smith@aa.org>
    To: J.Doe <joe@acme.com>
    Call-ID: 554565
    MIME-Version: 1.0
    Content-Type: multipart/encrypted;
        protocol="application/pgp-encrypted"; boundary=foo

Kirstein et al.                                                [PAGE 13]


Internet Draft                SIP Security                March 12, 1998

    --foo
    Content-Type: application/pgp-encrypted

    Version: 1

    --foo
    Content-Type: application/octet-stream

    -----BEGIN PGP MESSAGE-----
    > Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5;
    >           protocol="application/pgp-signature"
    >
    > --bar
    > Content-Type: text/plain; charset=iso-8859-1
    >
    > INVITE j.doe@acme.com SIP/2.1
    > From: Michael Elkins <elkins@aero.org>
    > To: J.Doe <joe@acme.com>
    > CALL-ID: 786598
    > Content-Type: application/sdp
    >
    > v=0
    > o=anybody 3098086191 3098086197 IN IP4 anycomputer.anywhere.com
    > s=general conference
    > i=This is a general conference
    > e=A. Nyone <anyone@anywhere.com>
    > p=A. Nyone +44 171 123 4567
    > c=IN IP4 239.255.140.52/15
    > t=3098084400 3098091600
    > a=tool:sdr v2.5a0
    > a=type:test
    > c=IN IP4 239.255.140.52/15
    > a=ptime:40
    >
    > --bar
    > Content-Type: application/pgp-signature
    >
    > -----BEGIN PGP MESSAGE-----
    > Version: 2.6.3i
    >
    > iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
    > jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
    > uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
    > HOxEa44b+EI=
    > =ndaj
    > -----END PGP MESSAGE-----
    >
    > --bar--
    -----END PGP MESSAGE-----

    --foo--

  The text preceded by '>' indicates that it is really encrypted, but
  presented as text for clarity.

Kirstein et al.                                                [PAGE 14]


Internet Draft                SIP Security                March 12, 1998

3.5.2 Combined Encryption and Signing

  PGP also allows data to be signed and encrypted in one operation.  As
  mentioned above both sending and receiving agents MUST support this
  format and this joint method has less overhead in terms of both data
  length and processing time. The resulting data should be formed as a
  "multipart/encrypted" object as described in Section 2.3. Messages,
  which are encrypted and signed in this combined fashion, are REQUIRED
  to follow the same canonicalization rules as for multipart/signed
  objects.

  Although only INVITE SIP messages have been used as examples in this
  document the format is applied in exactly the same way for the other
  method tokens mentioned above. This allows signature of ACK, BYE  etc
  SIP messages.

3.6 PGP Supported Algorithms

  In order to maintain wide interoperability the algorithms supported
  here follow [8] where fuller details can be found.

    1. Public Key Algorithms - Implementations MUST implement DSA [23]
        for signatures and  Elgamal for encryption. Implementations
        SHOULD implement RSA encryption [7].

    2. Symmetric Key Algorithm - Implementations MUST implement
        Triple-DES [24]. Implementations SHOULD implement IDEA and
        CAST5. Implementations MAY implement any other algorithm.

    3. Compression Algorithms - Implementations MUST implement
       uncompressed data. Implementations SHOULD implement ZIP.

    4. Hash Algorithms - Implementations MUST implement SHA-1 [26].
        Implementations SHOULD implement MD5.

4. SIP Security with S/MIME

  Support for the use of the S/MIME message format is OPTIONAL in this
  specification.

  The Cryptographic Message Syntax (CMS) is derived from PKCS#7 [14] and
  is fully defined in [15]. This syntax is used here to digitally sign
  or encrypt SIP messages and describes an encapsulation syntax for data
  protection. The CMS values are generated using ASN.1 [12] using BER
  encoding [13] and values are generally represented as octet strings.

  CMS associates a protection content type with a protection content and
  has ASN.1 type ContentInfo:

    ContentInfo ::= SEQUENCE {
      ContentType   ContentType,
      Content[0]    EXPLICIT ANY DEFINED BY contentType }

    ContentType ::= OBJECT IDENTIFIER

Kirstein et al.                                                [PAGE 15]


Internet Draft                SIP Security                March 12, 1998

  ContentType indicates the type of  protection content and is an Object
  Identifier. Six are defined in [15] but only Data, SignedData and
  EnvelopedData are of relevance to this document. Content is the actual
  protected content. Sending agents MUST use the "data" content type as
  the content within other content types to indicate the message content
  which has had security services applied to it. In addition sending
  agents MUST use the signedData content type to apply a digital
  signature to a message and an envelopedData type to encrypt a message.
  Further details of the specific requirements can be found in [9].

  Prior to any security enhancements the SIP message is converted into
  MIME canonical format exactly as described in [20] and discussed in
  Section 3.2. When S/MIME formats are used then these are as defined in
  [9,15] where more complete details can be found. These documents are,
  in turn, based on RFC 1847 [10] and PKCS#7 [14].

4.1 The application/pkcs7-mime Type

  The application/pkcs-7-mime type is used to carry CMS objects. This
  always carries a single CMS object which is the BER encoding of the
  ASN.1 syntax describing the object. The MIME headers of all
  application/pkcs-7-mime objects SHOULD include the optional
  "smime-type" parameters as described in [9].

4.2 Encryption Only with S/MIME

  The SIP message, which has been converted to MIME canonical format,
  is processed into a CMS [15] object of type envelopedData. This is
  then inserted into an applicaton/pkcs7-mime entity. The smime-type
  parameter for enveloped-only messages is "enveloped-data" and the
  file extension for this type of message is ".p7m".

  A sample message would be:

    INVITE j.doe@acme.com SIP/2.1
    From: John Smith <J.Smith@aa.org>
    To: J.Doe <joe@acme.com>
    Call-ID: 554565
    MIME-Version: 1.0
    Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
        name=smime.p7m
    Content-Transfer-Encoding: base64
    Content-Disposition: attachment; filename=smime.p7m

    rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
    7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
    f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
    0GhIGfHfQbnj756YT64V

4.3 Signing Only With S/MIME

  There are two possible formats for signed messages. One can either use
  application/pkcs7-mime and SignedData or multipart/signed. In general,
  the multipart/signed form is preferable for sending, and receiving

Kirstein et al.                                                [PAGE 16]


Internet Draft                SIP Security                March 12, 1998

  agents SHOULD be able to handle both. The receiver can always view
  messages signed using the multipart/signed format whether they have
  S/MIME software or not.  A recipient cannot view messages signed
  using the signedData format unless they have S/MIME facilities.

4.3.1 Signing Using application/pkcs7-mime and SignedData

  This signing format uses the application/pkcs7-mime MIME type as above
  but now the MIME entity and other required data is processed into a
  CMS object of type signedData. This is then inserted into an
  application/pkcs7-mime MIME entity. The smime-type parameter for
  messages using application/pkcs7-mime and SignedData is "signed-data"
  and the file extension for this type of message is ".p7m".

  A sample message would be:

    INVITE j.doe@acme.com SIP/2.1
    From: John Smith <J.Smith@aa.org>
    To: J.Doe <joe@acme.com>
    Call-ID: 554565
    MIME-Version: 1.0
    Content-Type: application/pkcs7-mime; smime-type=signed-data;
        name=smime.p7m
    Content-Transfer-Encoding: base64
    Content-Disposition: attachment; filename=smime.p7m

    567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7
    77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH
    HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh
    6YT64V0GhIGfHfQbnj75

4.3.2 Signing Using the multipart/signed Format

  This format is a clear-signing format and recipients with no S/MIME or
  PKCS processing facilities are able to view the message. It makes use
  of the multipart/signed MIME type described in RFC 1847 and the format
  is similar to the PGP signed-only SIP messages earlier. The
  multipart/signed MIME type has two parts. The first part contains the
  MIME entity that is to be signed; the second part contains the
  signature, which is a CMS detached signature.

  In order to create this type of message the SIP message is again
  converted to MIME canonical format as discussed in Section 3.2. This
  MIME entity is then processed to obtain a CMS object of type
  signedData with an empty contentInfo field. The MIME entity is then
  inserted into the first part of a multipart/signed message. Following
  this, transfer-encoding can, if desired, be applied to the detached
  signature and this is inserted into a MIME entity of type
  application/pkcs7-signature. This MIME entity is then inserted into
  the second part of the multipart/signed entity.

  The application/pkcs7-signature MIME type always contains a single CMS
  object of type signedData. The contentInfo field of the CMS object
  must be empty. The signerInfos field contains the signatures for the

Kirstein et al.                                                [PAGE 17]


Internet Draft                SIP Security                March 12, 1998

  MIME entity and the file extension for signed-only messages using
  application/pkcs7-signature is ".p7s".

  The multipart/signed content-type has two required parameters: the
  protocol parameter and the micalg parameter. The protocol parameter
  MUST be "application/pkcs7-signature". Note that quotation marks are
  required around the protocol parameter because MIME requires that the
  "/" character in the parameter value MUST be quoted. The micalg
  parameter allows for one-pass processing when the signature is being
  verified. The value of the micalg parameter is dependent on the
  message digest algorithm used in the calculation of the Message
  Integrity Check. The value of the micalg parameter SHOULD be one of
  the following:

      Algorithm:   MD5    SHA-1
          Value:   md5    sha1

  An example of a multipart/signed SIP Invitation would be:

    INVITE j.doe@acme.com SIP/2.1
    From: Michael Elkins <elkins@aero.org>
    To: Michael Elkins <elkins@aero.org>
    CALL-ID: 786598
    Mime-Version: 1.0
    Content-Type: multipart/signed;
        protocol="application/pkcs7-signature";
        micalg=sha1; boundary=boundary42

    --boundary42
    > Content-Type: text/plain; charset=iso-8859-1
    > Content-Transfer-Encoding: quoted-printable
    >
    > INVITE j.doe@acme.com SIP/2.1
    > To: J.Doe <joe@acme.com>
    > From: Michael Elkins <elkins@aero.org>
    > Subject: Videoconference on security issues
    > CALL-ID: 786598
    >
    > Content-Type: application/sdp
    >
    > v=0
    > o=anybody 3098086191 3098086197 IN IP4 anycomputer.anywhere.com
    > s=general conference
    > i=This is a general conference
    > e=A. Nyone <anyone@anywhere.com>
    > p=A. Nyone +44 171 123 4567
    > c=IN IP4 239.255.140.52/15
    > t=3098084400 3098091600
    > a=tool:sdr v2.5a0
    > a=type:test
    > m=audio 19274 RTP/AVP 0
    > c=IN IP4 239.255.140.52/15
    > a=ptime:40
    >

Kirstein et al.                                                [PAGE 18]


Internet Draft                SIP Security                March 12, 1998

    --boundary42
    Content-Type: application/pkcs7-signature; name=smime.p7s
    Content-Transfer-Encoding: base64
    Content-Disposition: attachment; filename=smime.p7s

    ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
    4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
    n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
    7GhIGfHfYT64VQbnj756

    --boundary42--

  The ">" indicate the data included in the signature.

4.4 Signing and Encrypting

  To achieve signing and encrypting, any of the signed-only and
  encrypted-only formats may be nested. This is allowed because the
  above formats are all MIME entities, and because they all secure MIME
  entities. A secure SIP implementation MUST be able to receive and
  process arbitrarily nested S/MIME within reasonable resource limits of
   the recipient computer.

  It is possible to either sign a message first, or to envelope the
  message first. It is up to the implementor and the user to choose.
  When signing first, the enveloping then securely obscures the
  signatories. When enveloping first the signatories are exposed, but it
  is possible to verify signatures without removing the enveloping. This
  may be useful in an environment where automatic signature verification
  is desired, as no private key material is required to verify a
  signature.

4.5 S/MIME Supported Algorithms

  In order to maintain wide interoperability the algorithms supported
  here follow [9] where fuller details can be found.

    1. KeyEncryptionAlgorithmIdentifier

        Sending and receiving agents MUST support Diffie-Hellman defined
        in [22].

        Receiving agents SHOULD support rsaEncryption [7]. Incoming
        encrypted messages contain symmetric keys which are to be
        decrypted with a user's private key. The size of the private key
        is determined during key generation.

        Sending agents SHOULD support rsaEncryption. Sending agents
        SHOULD support rsaEncryption encryption. If an agent supports
        rsaEncryption then it MUST support encryption of symmetric keys
        with RSA public keys at key sizes from 512 bits to 1024 bits.




Kirstein et al.                                                [PAGE 19]


Internet Draft                SIP Security                March 12, 1998

    2. SignatureAlgorithmIdentifier

        Sending and receiving agents MUST support id-dsa defined in
        [23]. The algorithm parameters MUST be absent (not encoded as
        NULL).

        Receiving agents SHOULD support rsaEncryption, defined in [7].
        Receiving agents SHOULD support verification of signatures using
        RSA public key sizes from 512 bits to 1024 bits.

        Sending agents SHOULD support rsaEncryption. Outgoing messages
        are signed with a user's private key.

    3. ContentEncryptionAlgorithmIdentifier

        Receiving agents MUST support encryption and decryption with
        DES EDE3 CBC [24]. Receiving agents SHOULD support encryption
        and decryption using the RC2 [25] or a compatible algorithm at
        a key size of 40 bits.

    4. DigestAlgorithmIdentifier

        Receiving agents MUST support SHA-1 [26].  Receiving agents
        SHOULD support MD5 [27].

        Sending agents SHOULD use SHA-1.





























Kirstein et al.                                                [PAGE 20]


Internet Draft                SIP Security                March 12, 1998


                               References


 [1] M.Handley "SAP: Session Announcement Protocol"
    Internet Draft: draft-ietf-mmusic-sap-00.txt, 27/Nov/96

 [2] M. Handley, H. Schulzrinne and E. Schooler
    "SIP: Session Initiation Protocol"
    Internet Draft: draft-ietf-mmusic-sip-04.txt, Nov 97

 [3] D. Crocker "Standard for the Format of ARPA Internet Text Messages"
    STD 11, RFC 822, University of Delaware, August 1982

 [4] M. Handley and V. Jacobson "SDP: Session Description Protocol"
    Internet Draft: draft-ietf-mmusic-sdp-06.txt, Jan 97

 [5] H. Schulzrinne, A. Rao and R. Lanphier
    "Real Time Streaming Protocol (RTSP)"
    IETF, Internet Draft, July 97 Work In Progress

 [6] A. Freier, P. Karlton and P. Kocher "The SSL Protocol: Version 3.0"
    Internet Draft: draft-ietf-tls-ssl-version3-00.txt, Nov 96

 [7] R.L. Rivest, A. Shamir and L.M. Adleman
    "A Method for Obtaining Digital Signatures and Public Key
    Cryptosystems",
    Communications of the ACM, v. 21, n. 2, Feb 1978, pp 120-126

    PKCS#1 "RSA Encryption Standard"
    RSA Laboratories, Version 1.5, Nov 1993

 [8] J. Callas "OpenPGP Message Formats"
    Internet Draft: draft-ietf-openpgp-formats-00.txt, Nov 1998

 [9] B. Ramsdell "S/MIME Version 3 Message Specification"
    Internet Draft: draft-ietf-smime-msg-01.txt, Jan 1998

[10] J. Galvin et al
     "Security Multiparts for MIME: Multipart/Signed and
     Multipart/Encrypted"
     Technical Report RFC 1847, IETF, Oct 1995

[11] M. Elkins "MIME Security With Pretty Good Privacy"
     Technical Report RFC 2015, IETF, Oct 1996

[12] X.208 "Specification of Abstract Syntax Notation One (ASN.1)"
     ITU-T Recommendations, 1988

[13] X.209 "BER: Basic Encoding Rules for ASN.1"
     ITU-T Recommendations, 1988

[14] PKCS#7 "Cryptographic Message Syntax Standard"
     RSA Laboratories, Version 1.5, Nov 1993

Kirstein et al.                                                [PAGE 21]


Internet Draft                SIP Security                March 12, 1998

[15] R. Housley "Cryptographic Message Syntax"
     Internet Draft: draft-ietf-smime-cms-03.txt, Jan 1998

[16] Fielding et al "Hypetext transfer Protocol - HTTP/1.1"
     Technical Report RFC 2068, IETF, Jan 1997

[17] D. Crocker "Augmented BNF for Syntax Specifications: ABNF"
     IETF, Internet Draft, Oct 1996, Work In Progress

[18] J. C. Mogul and S. E. Deering "Path MTU Discovery"
     Technical Report RFC 1191, IETF, Nov 1990

[19] W. R. Stevens "TCP/IP Illustrated: The Protocols"
     Vol 1, Reading, Massachusetts. Pub: Addison-Wesley, 1994

[20] N. Freed and N. Borenstein
     "MIME: Part One. Format of internet Message Bodies"
     Technical Report RFC 2045, IETF, Nov 1996

     N. Freed and N. Borenstein
     "MIME: Part Two. Media Types"
     Technical Report RFC 2046, IETF, Nov 1996

     K. Moore
     "MIME: Part Three. Message header Extensions for Non-ASCII Text"
     Technical Report RFC 2047, IETF, Nov 1996

     N. Freed et al
     "MIME: Part Four. Registration Procedures"
     Technical Report RFC 2048, IETF, Nov 1996

     N. Freed and N. Borenstein
     "MIME: Part Five. Conformance Criteria and Examples"
     Technical Report RFC 2049, IETF, Nov 1996

[21] Character sets assigned by IANA.
     See <ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets>

[22] ANSI X9.42

[23] ANSI X9.57-1997x,
     "Public Key Cryptography for the Financial Services Industry:
     Certificate Management". Working Draft, June 1996

[24] ANSI X3.106
     "American National Standards for Information Systems - Data Link
     Encryption"
     American National Standards Institute, 1983 (DES)

     W. Tuchman "Hellman Presents No Shortcuts Solutions to DES"
     IEEE Spectrum, v16, n7, pp40-41, July 1979

[25] R.L. Rivest et al "Description of the RC2 Encryption Algorithm"
     Internet Draft: draft-rivest-rc2desc-01.txt

Kirstein et al.                                                [PAGE 23]


Internet Draft                SIP Security                March 12, 1998

[26] NIST FIPS PUB 180-1 "Secure Hash Standard"
     National Institute of Standards and Technology,
     U.S. Dept. of Commerce, DRAFT, May 1994

[27] R. L. Rivest "The MD5 Message Digest Algorithm"
     Technical Report RFC 1321, IETF, April 1992

[28] Bradner "Key words for use in RFCs to indicate Requirement Level"
     Technical Report RFC 2119, IETF, March 1997





                       Authors' Addresses


  Peter Kirstein, Goli Montasser Kohsari and Edmund Whelan are at
  University College London and their contact details are:

        P.Kirstein@cs.ucl.ac.uk            Tel: +44 171 380 7286
        G.Montasser-Kohsari@cs.ucl.ac.uk   Tel: +44 171 380 7215
        E.Whelan@cs.ucl.ac.uk              Tel: +44 171 419 3688

        Dept of Computer Science           Fax: +44 171 387 1397
        University College London
        Gower Street
        London WC1E 6BT England





                         Acknowledgements


  The European Commission, under the Telematics 1007 "MERCI" project and
  the Telematics 1005 "ICE-TEL" project, funded the design of SIP
  Security. Mark Handely, Henning Schulzrinne and Eve Schooler developed
  the original SIP draft.















Kirstein et al.                                                [PAGE 24]


Html markup produced by rfcmarkup 1.122, available from https://tools.ietf.org/tools/rfcmarkup/