Ticket #61: imported libsrtp into third_party directory (backported from srtp branch)
git-svn-id: https://svn.pjsip.org/repos/pjproject/trunk@1730 74dad513-b988-da41-8d7b-12977e46ad98
diff --git a/third_party/srtp/doc/intro.txt b/third_party/srtp/doc/intro.txt
new file mode 100644
index 0000000..f315599
--- /dev/null
+++ b/third_party/srtp/doc/intro.txt
@@ -0,0 +1,395 @@
+/**
+
+@mainpage Introduction to libSRTP
+
+This document describes libSRTP, the Open Source Secure RTP library
+from Cisco Systems, Inc. RTP is the Real-time Transport Protocol, an
+IETF standard for the transport of real-time data such as telephony,
+audio, and video, defined by RFC1889. Secure RTP (SRTP) is an RTP
+profile for providing confidentiality to RTP data and authentication
+to the RTP header and payload. SRTP is an IETF Proposed Standard, and
+is defined in RFC 3711, and was developed in the IETF Audio/Video
+Transport (AVT) Working Group. This library supports all of the
+mandatory features of SRTP, but not all of the optional features. See
+the @ref Features section for more detailed information.
+
+This document is organized as follows. The first chapter provides
+background material on SRTP and overview of libSRTP. The following
+chapters provide a detailed reference to the libSRTP API and related
+functions. The reference material is created automatically (using the
+doxygen utility) from comments embedded in some of the C header
+files. The documentation is organized into modules in order to improve
+its clarity. These modules do not directly correspond to files. An
+underlying cryptographic kernel provides much of the basic
+functionality of libSRTP, but is mostly undocumented because it does
+its work behind the scenes.
+
+@section LICENSE License and Disclaimer
+
+libSRTP is distributed under the following license, which is included
+in the source code distribution. It is reproduced in the manual in
+case you got the library from another source.
+
+@latexonly
+\begin{quote}
+Copyright (c) 2001-2005 Cisco Systems, Inc. All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+\begin{itemize}
+\item Redistributions of source code must retain the above copyright
+ notice, this list of conditions and the following disclaimer.
+\item Redistributions in binary form must reproduce the above
+ copyright notice, this list of conditions and the following
+ disclaimer in the documentation and/or other materials provided
+ with the distribution.
+\item Neither the name of the Cisco Systems, Inc. nor the names of its
+ contributors may be used to endorse or promote products derived
+ from this software without specific prior written permission.
+\end{itemize}
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
+INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+OF THE POSSIBILITY OF SUCH DAMAGE.
+\end{quote}
+@endlatexonly
+
+@section Features Supported Features
+
+This library supports all of the mandatory-to-implement features of
+SRTP (as defined by the most recent Internet Draft). Some of these
+features can be selected (or de-selected) at run time by setting an
+appropriate policy; this is done using the structure srtp_policy_t.
+Some other behaviors of the protocol can be adapted by defining an
+approriate event handler for the exceptional events; see the @ref
+SRTPevents section.
+
+Some options that are not included in the specification are supported.
+Most notably, the TMMH authentication function is included, though it
+was removed from the SRTP Internet Draft during the summer of 2002.
+
+
+@latexonly
+Some options that are described in the SRTP specification are not
+supported. This includes
+\begin{itemize}
+\item the Master Key Index (MKI),
+\item key derivation rates other than zero,
+\item the cipher F8,
+\item anti-replay lists with sizes other than 128,
+\item the use of the packet index to select between master keys.
+\end{itemize}
+@endlatexonly
+
+The user should be aware that it is possible to misuse this libary,
+and that the result may be that the security level it provides is
+inadequate. If you are implementing a feature using this library, you
+will want to read the Security Considerations section of the Internet
+Draft. In addition, it is important that you read and understand the
+terms outlined in the @ref LICENSE section.
+
+
+@section Installing Installing and Building libSRTP
+
+@latexonly
+
+To install libSRTP, download the latest release of the distribution
+from \texttt{srtp.sourceforge.net}. The format of the names of the
+distributions are \texttt{srtp-A.B.C.tgz}, where \texttt{A} is the
+version number, \texttt{B} is the major release number, \texttt{C} is
+the minor release number, and \texttt{tgz} is the file
+extension\footnote{The extension \texttt{.tgz} is identical to
+\texttt{tar.gz}, and indicates a compressed tar file.} You probably
+want to get the most recent release. Unpack the distribution and
+extract the source files; the directory into which the soruce files
+will go is named \texttt{srtp}.
+
+libSRTP uses the GNU \texttt{autoconf} and \texttt{make}
+utilities\footnote{BSD make will not work; if both versions of make
+are on your platform, you can invoke GNU make as \texttt{gmake}.}. In
+the \texttt{srtp} directory, run the configure script and then make:
+\begin{verbatim}
+ ./configure [ options ]
+ make
+\end{verbatim}
+The configure script accepts the following options:
+\begin{quote}
+\begin{description}
+\item[--help] provides a usage summary.
+\item[--disable-debug] compiles libSRTP without the runtime
+ dynamic debugging system.
+\item[--enable-generic-aesicm] compile in changes for ismacryp
+\item[--enable-syslog] use syslog for error reporting.
+\item[--disable-stdout] diables stdout for error reporting.
+\item[--enable-console] use \texttt{/dev/console} for error reporting
+\item[--gdoi] use GDOI key management (disabled at present).
+\end{description}
+\end{quote}
+
+By default, dynamic debbuging is enabled and stdout is used for
+debugging. You can use the configure options to have the debugging
+output sent to syslog or the system console. Alternatively, you can
+define ERR\_REPORTING\_FILE in \texttt{include/conf.h} to be any other
+file that can be opened by libSRTP, and debug messages will be sent to
+it.
+
+This package has been tested on the following platforms: Mac OS X
+(powerpc-apple-darwin1.4), Cygwin (i686-pc-cygwin), Solaris
+(sparc-sun-solaris2.6), RedHat Linux 7.1 and 9 (i686-pc-linux), and
+OpenBSD (sparc-unknown-openbsd2.7).
+
+
+@endlatexonly
+
+@section Applications Applications
+
+@latexonly
+
+Several test drivers and a simple and portable srtp application are
+included in the \texttt{test/} subdirectory.
+
+\begin{center}
+\begin{tabular}{ll}
+\hline
+Test driver & Function tested \\
+\hline
+kernel\_driver & crypto kernel (ciphers, auth funcs, rng) \\
+srtp\_driver & srtp in-memory tests (does not use the network) \\
+rdbx\_driver & rdbx (extended replay database) \\
+roc\_driver & extended sequence number functions \\
+replay\_driver & replay database \\
+cipher\_driver & ciphers \\
+auth\_driver & hash functions \\
+\hline
+\end{tabular}
+\end{center}
+
+The app rtpw is a simple rtp application which reads words from
+/usr/dict/words and then sends them out one at a time using [s]rtp.
+Manual srtp keying uses the -k option; automated key management
+using gdoi will be added later.
+
+The usage for rtpw is
+
+\texttt{rtpw [[-d $<$debug$>$]* [-k $<$key$>$ [-a][-e]] [-s | -r] dest\_ip
+dest\_port][-l]}
+
+Either the -s (sender) or -r (receiver) option must be chosen. The
+values dest\_ip, dest\_port are the IP address and UDP port to which
+the dictionary will be sent, respectively. The options are:
+\begin{center}
+\begin{tabular}{ll}
+ -s & (S)RTP sender - causes app to send words \\
+ -r & (S)RTP receive - causes app to receve words \\
+ -k $<$key$>$ & use SRTP master key $<$key$>$, where the
+ key is a hexadecimal value (without the
+ leading "0x") \\
+ -e & encrypt/decrypt (for data confidentiality)
+ (requires use of -k option as well)\\
+ -a & message authentication
+ (requires use of -k option as well) \\
+ -l & list the avaliable debug modules \\
+ -d $<$debug$>$ & turn on debugging for module $<$debug$>$ \\
+\end{tabular}
+\end{center}
+
+In order to get a random 30-byte value for use as a key/salt pair, you
+can use the \texttt{rand\_gen} utility in the \texttt{test/}
+subdirectory.
+
+An example of an SRTP session using two rtpw programs follows:
+
+\begin{verbatim}
+[sh1] set k=`test/rand_gen -n 30`
+[sh1] echo $k
+c1eec3717da76195bb878578790af71c4ee9f859e197a414a78d5abc7451
+[sh1]$ test/rtpw -s -k $k -ea 0.0.0.0 9999
+Security services: confidentiality message authentication
+set master key/salt to C1EEC3717DA76195BB878578790AF71C/4EE9F859E197A414A78D5ABC7451
+setting SSRC to 2078917053
+sending word: A
+sending word: a
+sending word: aa
+sending word: aal
+sending word: aalii
+sending word: aam
+sending word: Aani
+sending word: aardvark
+...
+
+[sh2] set k=c1eec3717da76195bb878578790af71c4ee9f859e197a414a78d5abc7451
+[sh2]$ test/rtpw -r -k $k -ea 0.0.0.0 9999
+security services: confidentiality message authentication
+set master key/salt to C1EEC3717DA76195BB878578790AF71C/4EE9F859E197A414A78D5ABC7451
+19 octets received from SSRC 2078917053 word: A
+19 octets received from SSRC 2078917053 word: a
+20 octets received from SSRC 2078917053 word: aa
+21 octets received from SSRC 2078917053 word: aal
+...
+\end{verbatim}
+
+
+@endlatexonly
+
+
+@section Review Secure RTP Background
+
+In this section we review SRTP and introduce some terms that are used
+in libSRTP. An RTP session is defined by a pair of destination
+transport addresses, that is, a network address plus a pair of UDP
+ports for RTP and RTCP. RTCP, the RTP control protocol, is used to
+coordinate between the participants in an RTP session, e.g. to provide
+feedback from receivers to senders. An @e SRTP @e session is
+similarly defined; it is just an RTP session for which the SRTP
+profile is being used. An SRTP session consists of the traffic sent
+to the SRTP or SRTCP destination transport addresses. Each
+participant in a session is identified by a synchronization source
+(SSRC) identifier. Some participants may not send any SRTP traffic;
+they are called receivers, even though they send out SRTCP traffic,
+such as receiver reports.
+
+RTP allows multiple sources to send RTP and RTCP traffic during the
+same session. The synchronization source identifier (SSRC) is used to
+distinguish these sources. In libSRTP, we call the SRTP and SRTCP
+traffic from a particular source a @e stream. Each stream has its own
+SSRC, sequence number, rollover counter, and other data. A particular
+choice of options, cryptographic mechanisms, and keys is called a @e
+policy. Each stream within a session can have a distinct policy
+applied to it. A session policy is a collection of stream policies.
+
+A single policy can be used for all of the streams in a given session,
+though the case in which a single @e key is shared across multiple
+streams requires care. When key sharing is used, the SSRC values that
+identify the streams @b must be distinct. This requirement can be
+enforced by using the convention that each SRTP and SRTCP key is used
+for encryption by only a single sender. In other words, the key is
+shared only across streams that originate from a particular device (of
+course, other SRTP participants will need to use the key for
+decryption). libSRTP supports this enforcement by detecting the case
+in which a key is used for both inbound and outbound data.
+
+
+@section Overview libSRTP Overview
+
+libSRTP provides functions for protecting RTP and RTCP. RTP packets
+can be encrypted and authenticated (using the srtp_protect()
+function), turning them into SRTP packets. Similarly, SRTP packets
+can be decrypted and have their authentication verified (using the
+srtp_unprotect() function), turning them into RTP packets. Similar
+functions apply security to RTCP packets.
+
+The typedef srtp_stream_t points to a structure holding all of the
+state associated with an SRTP stream, including the keys and
+parameters for cipher and message authentication functions and the
+anti-replay data. A particular srtp_stream_t holds the information
+needed to protect a particular RTP and RTCP stream. This datatype
+is intentionally opaque in order to better seperate the libSRTP
+API from its implementation.
+
+Within an SRTP session, there can be multiple streams, each
+originating from a particular sender. Each source uses a distinct
+stream context to protect the RTP and RTCP stream that it is
+originating. The typedef srtp_t points to a structure holding all of
+the state associated with an SRTP session. There can be multiple
+stream contexts associated with a single srtp_t. A stream context
+cannot exist indepent from an srtp_t, though of course an srtp_t can
+be created that contains only a single stream context. A device
+participating in an SRTP session must have a stream context for each
+source in that session, so that it can process the data that it
+receives from each sender.
+
+
+In libSRTP, a session is created using the function srtp_create().
+The policy to be implemented in the session is passed into this
+function as an srtp_policy_t structure. A single one of these
+structures describes the policy of a single stream. These structures
+can also be linked together to form an entire session policy. A linked
+list of srtp_policy_t structures is equivalent to a session policy.
+In such a policy, we refer to a single srtp_policy_t as an @e element.
+
+An srtp_policy_t strucutre contains two crypto_policy_t structures
+that describe the cryptograhic policies for RTP and RTCP, as well as
+the SRTP master key and the SSRC value. The SSRC describes what to
+protect (e.g. which stream), and the crypto_policy_t structures
+describe how to protect it. The key is contained in a policy element
+because it simplifies the interface to the library. In many cases, it
+is desirable to use the same cryptographic policies across all of the
+streams in a session, but to use a distinct key for each stream. A
+crypto_policy_t structure can be initialized by using either the
+crypto_policy_set_rtp_default() or crypto_policy_set_rtcp_default()
+functions, which set a crypto policy structure to the default policies
+for RTP and RTCP protection, respectively.
+
+@section Example Example Code
+
+This section provides a simple example of how to use libSRTP. The
+example code lacks error checking, but is functional. Here we assume
+that the value ssrc is already set to describe the SSRC of the stream
+that we are sending, and that the functions get_rtp_packet() and
+send_srtp_packet() are available to us. The former puts an RTP packet
+into the buffer and returns the number of octets written to that
+buffer. The latter sends the RTP packet in the buffer, given the
+length as its second argument.
+
+@verbatim
+ srtp_t session;
+ srtp_policy_t policy;
+ uint8_t key[30];
+
+ // initialize libSRTP
+ srtp_init();
+
+ // set policy to describe a policy for an SRTP stream
+ crypto_policy_set_rtp_default(&policy.rtp);
+ crypto_policy_set_rtcp_default(&policy.rtcp);
+ policy.ssrc = ssrc;
+ policy.key = key;
+ policy.next = NULL;
+
+ // set key to random value
+ crypto_get_random(key, 30);
+
+ // allocate and initialize the SRTP session
+ srtp_create(&session, policy);
+
+ // main loop: get rtp packets, send srtp packets
+ while (1) {
+ char rtp_buffer[2048];
+ unsigned len;
+
+ len = get_rtp_packet(rtp_buffer);
+ srtp_protect(session, rtp_buffer, &len);
+ send_srtp_packet(rtp_buffer, len);
+ }
+@endverbatim
+
+@section ISMAcryp ISMA Encryption Support
+
+The Internet Streaming Media Alliance (ISMA) specifies a way
+to pre-encrypt a media file prior to streaming. This method
+is an alternative to SRTP encryption, which is potentially
+useful when a particular media file will be streamed
+multiple times. The specification is available online
+at http://www.isma.tv/specreq.nsf/SpecRequest.
+
+libSRTP provides the encryption and decryption functions needed for ISMAcryp
+in the library @t libaesicm.a, which is included in the default
+Makefile target. This library is used by the MPEG4IP project; see
+http://mpeg4ip.sourceforge.net/.
+
+Note that ISMAcryp does not provide authentication for
+RTP nor RTCP, nor confidentiality for RTCP.
+ISMAcryp RECOMMENDS the use of SRTP message authentication for ISMAcryp
+streams while using ISMAcryp encryption to protect the media itself.
+
+
+ */