Internet Engineering Task Force MMUSIC WG
Internet Draft P. Kirstein
draft-ietf-mmusic-sap-sec-04.txt G. Montasser-Kohsari
March 12th 1998 E. Whelan
Expires: September 12th 1998 University College London
SAP 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 Announcement Protocol (SAP) has been specified in such a way
that authentication and privacy can be assured. However the algorithms
and mechanisms to achieve such security are not prescribed in the
current draft. This document extends the SAP protocol, by describing
specific algorithms and formats of authentication and encryption formats
based on PGP and PKCS#7 standards. It is a companion document to
draft-ietf-mmusic-sap.
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
GLOSSARY
ASN Abstract Syntax Notation
CT Content Type
CTB Cipher Type Byte
DA Digest Algorithm
DEA Digest Encryption Algorithm
DES Data Encryption Standards
EAID Encryption Algorithm Identifier
EK Encryption Key
EKID Encryption Key Identifier
IETF Internet Engineering Task Force
MD Message Digest
MMUSIC Multiparty Multimedia Session Control
PEM Privacy Enhanced Mail
PGP Pretty Good Privacy
PH Privacy Header
PK Public Key
PKCS Public Key Cryptographic System
PKCS Public Key Cryptography Standard (as in PKCS#7)
SAP Session Announcement Protocol
SDP Session Descriptor Protocol
SEK Session Encryption Key
SK Secret Key
SGK Group Key
SHA Hash Algorithm
Kirstein et al. [PAGE 2]
Internet Draft SIP Security March 12, 1998
Table of Contents
Table of Contents ................................................ 3
1. Introduction .................................................. 4
2. Authentication and Encryption of Announcements ................ 4
2.1 Introduction ............................................... 4
2.2 Symmetric and Asymmetric Encryption ........................ 5
2.3 Authenticated Announcements ................................ 5
2.4 Authenticated and Encrypted Announcements .................. 6
2.4.1 Introduction ........................................... 6
2.4.2 Distribution of Session Encryption Keys ................ 6
2.4.3 Use of Public Key Algorithms ........................... 7
2.4.4 Encrypting Announcements ............................... 8
2.4.5 Decrypting Announcements ............................... 8
3. Secured SAP Packet Formats .................................... 8
3.1 Secured SAP Packet Format .................................. 9
3.2 Authentication Header ...................................... 11
3.2.1 Generic Format ......................................... 11
3.2.2 PGP Format ............................................. 12
3.2.3 PKCS#7 Format .......................................... 12
3.3 Encrypted Payload Format ..................................... 13
3.3.1 Generic Format ........................................... 13
3.3.2 Symmetric Encryption ..................................... 13
3.3.3 Hybrid Encryption ........................................ 14
3.3.3.1 PGP Format Privacy Header .......................... 14
3.3.3.2 PKCS#7 Format Privacy Header ....................... 15
3.3.4 Supported Algorithms ..................................... 15
3.3.4.1 Symmetric Encryption ............................... 15
3.3.4.2 Hybrid Encryption .................................. 15
3.3.4.2.1 PGP Format ................................... 15
3.3.4.2.2 PKCS#7 Format ................................ 15
4 Changes from Previous Draft .................................. 16
References ..................................................... 17
Authors' Addresses ............................................. 18
Acknowledgements ............................................... 18
Kirstein et al. [PAGE 3]
Internet Draft SIP Security March 12, 1998
1. Introduction
An Mbone session directory is used to advertise multimedia conferences,
and to communicate the session addresses (whether multicast or unicast)
and conference-tool- specific information necessary for participation.
Such sessions are be announced using the Session Announcement Protocol
(SAP) described in a companion draft [1]. The SAP protocol allows for
the incorporation of authentication of the announcement originator, and
for privacy of the session details; however neither the choice of
authentication algorithms used, nor the mechanisms for encrypting the
SDP Session Description, are detailed in the draft.
This document describes the format of the authentication header for SAP
data packets that use security services based on PGP [2] or PKCS#7 [3].
The SAP document also provides for the confidentiality services required
for the SDP payload [4], which describes the conference set-up
parameters. This document describes how both symmetric and hybrid
symmetric/public key encryption algorithms should be used to provide
private announcements.
Much of this document is concerned with security considerations. This
document is currently in the process of peer review and, until the
process has been completed, should not be considered authoritative in
this area.
2. Authentication and Encryption of Announcements
2.1 Introduction
It is necessary to provide authentication and integrity of the Session
Announcement to ensure that only authorised persons modify Session
Announcements and to provide facilities for announcing securely
encrypted sessions - providing the relevant proposed conferees with the
means to decrypt the data streams. The Session Announcements are made to
announce to all potential conferees the existence of a conference. It
has, however, another function - to try to minimise conflicts for Mbone
resources by spreading out the number of simultaneous conferences. Thus
there are a number of threats which we must try to address in the
securing of the Session Announcement, and some constraints. These
include the following:
- Authentication and Integrity of Session Announcement
Here it is necessary to ensure that the Session Announcement comes from
the person claimed, and is indeed an authorised announcement. Since
subsequent announcements will modify caches of future conferences, it is
possible otherwise to spoof an original announcement, and thereby at
least cause a Denial of Service attack.
- Confidentiality of Conference Details for Session Announcement
Here it is at least necessary to hide the details of the addresses and
media formats used. In order to minimise schedule conflicts; it is
desirable to keep at least the time of a conference known, even if all
Kirstein et al. [PAGE 4]
Internet Draft SIP Security March 12, 1998
other details are concealed.
Three types of announcement are supported: 'unsecured', 'authenticated'
and 'authenticated and encrypted'. The 'unsecured' type is described in
the SAP specification [1] and so only the latter two types are described
below.
2.2 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[10]) 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.
Two complete systems, which can achieve both authentication and
confidentiality using particular PKCS systems, are PGP [2] and PKCS#7
[3]; similar mechanisms are used, but different encryption algorithms
and formats are used. The differences between the algorithm and format
details for these two systems are elaborated in Sections 3.2 and 3.3.
As detailed later implementers MUST support PGP with support for PKCS#7
being OPTIONAL.
2.3 Authenticated Announcements
In order to send authenticated announcements it is possible to use the
algorithms of either PGP [2] or the PKCS#7 [3] systems. The resulting
format will be substantially different; the exact details are given in
Kirstein et al. [PAGE 5]
Internet Draft SIP Security March 12, 1998
Sections 3.2 and 3.3. For each format, the announcement originator
calculates a message digest of the announcement. The originator's
secret key is used to encrypt the message digest, together with an
electronic timestamp, thus forming a digital signature. The originator
sends the digital signature along with the message; the receiver
receives the message and the digital signature, and recovers the
original message digest from the digital signature by decrypting it
with the sender's public key. The receiver computes a new message
digest from the message, and checks to see if it matches the one
recovered from the digital signature. If it matches, then this is
considered adequate proof that the message was not altered, and that it
came from the originator who owns the public key used to check the
signature.
Each Session announcement contains a message ID hash [4]. The
specifications for SAP announcements [1] states that such announcements
may be repeated frequently, but that if any change is made in the
announcement, a different message ID must be used; as a result, a
different message ID hash will be appended to the message. As a result,
it is only necessary to authenticate an announcement the first time it
is received.
To save space in the announcement message, only a public key identifier
is generally included. It is then assumed that the public key itself
has either been distributed previously or can be retrieved from a cache
or directory. Optionally the Public Key itself can be included in the
announcement in the form of a certificate removing the need for prior
distribution. Consequently, providing that the Public Key is already
available in a local cache or Directory, or is distributed with the
announcement, one can be sure that the same originator sent the
announcement. Only if the full public key information, and a Certificate
Authority infrastructure, are accessible, can the originator be
identified [5].
2.4 Authenticated and Encrypted Announcements
2.4.1 Introduction
When it is desired to make private announcements, it is necessary to
encrypt the set-up details of the conference. The normal way of
providing such encryption is to use only a symmetric encryption
algorithm such as the Data Encryption Standard (DES [6]) to encrypt
such a session using a Session Encryption Key (SEK); this algorithm is
used because other systems, such as the asymmetric RSA system [10], are
too computation-intensive for large amounts of data - though they are
economic for smaller amounts. For symmetric encryption systems, the SEK
must be securely distributed to all authorised recipients.
2.4.2 Distribution of Session Encryption Keys
There are various ways that the SEK could be distributed; all rely on
distributing some shared secret in advance to the intended participants
in the conference group. When this process takes place out of band, it
is not described further in this document.
Kirstein et al. [PAGE 6]
Internet Draft SIP Security March 12, 1998
Many symmetric encryption algorithms, e.g. DES [6] are known to be easy
to break; with such algorithms, it is undesirable to re-use the SEK many
times. For this reason, and to improve security, a set of SEKs may be
distributed out-of-band; the recipients may then try to decrypt the
announcement by trying each of these SEKs in turn.
As in Section 2.3, one may use the fact that if any change is made in
the announcement, a different message ID, and hence message ID hash is
used; it is only necessary to attempt to decrypt an announcement message
the first time it is received. The basic symmetric system is contained
in SAP [1]. To improve efficiency, it would be possible to use
symmetric encryption with a pre-distributed Key Identifier (KeyID).
However, because of the potential weakening of the security by the use
of KeyIDs, and the consequent need to use more secure symmetric
algorithms, we do not recommend this technique. Moreover, by adopting
the use of asymmetric Public Key technology for such SEK distribution as
discussed below, we gain both efficiency and have a better integrated
approach to authentication.
2.4.3 Use of Public Key Algorithms
Public Key Cryptography is one mechanism for minimising the need for
secure transmission of shared secrets; this was already used in the
Authenticated Announcements of Section 2.2. It would be possible to use
these encryption algorithms on the whole announcement message but this
would be inefficient because the asymmetric encryption algorithms
normally use much longer encryption keys, and are much more resource
intensive, than the symmetric ones. For this reason it is more efficient
to use a combination of symmetric and Public Key algorithms. Now a
random Session Encryption Key (SEK) is generated as in Section 2.4.1. A
Privacy Header (PH) is constructed containing the SEK, which is
encrypted with the asymmetric encryption algorithm. It is now only
necessary to distribute a Secret Group Key (SGK) and Public Group Key
(PGK) i.e. {SGK, PGK} to decrypt the SEK. However, this pair needs to be
distributed only once as long as the group membership does not change;
it is possible to re-use the same group keys for many sessions, with
different SEKs. This minimises the number of times the prior key
distribution sequence must be followed.
It should be noted that because a Group Key is used in the above, it is
not possible to use the same Header to authenticate the sender uniquely,
though it is authenticated automatically that the sender is one of the
group which has reserved the asymmetric encryption key pair. It is
still possible to authenticate the identity of the sender by using a
different Authentication Key for the Authentication Header as described
in Section 2.3.
It would be possible to use a similar technique using symmetric
encryption with a strong encryption algorithm and an encryption key
Identifier instead of the Public Key Group Key, However, we believe the
Public Key method to be superior so this variant is not pursued.
Kirstein et al. [PAGE 7]
Internet Draft SIP Security March 12, 1998
2.4.4 Encrypting Announcements
We will now provide some more detail. If the payload is to be
compressed, this is performed prior to encryption as the probability
that ciphertext can be appreciably compressed is small.
When an announcement is to be encrypted, the payload is encrypted using
symmetric encryption. In this case each such encryption key is used only
once; a new Session Encryption Key (SEK) is generated as a random number
for each announcement. Since it is to be used only once, the SEK is
bound to the message and transmitted with it in a Privacy Header. The
sequence is as follows: The Privacy Header contains the SEK, encrypted
with the group's Public Group Key, together with information identifying
the Group Key which has been used. The encrypted Payload is appended to
the Privacy Header.
2.4.5 Decrypting Announcements
Upon receiving a new announcement with the encryption bit set, a
receiver should attempt to decrypt the announcement with the relevant
group private key or their own private key as indicated in the Privacy
Header. The sequence is as follows:
1. Prior to the announcement, the group's Public/Secret Group Key
pair is distributed securely.
2. From the announcement, the receiving participants determine
which Public Group Key has been used by looking at the
information contained in the Privacy Header.
3. They then decrypt the Session Encryption Key (SEK) with the SGK
corresponding to the PGK identified in Step 2 and obtain other
necessary information such as the content encryption algorithm
from the Privacy Header.
4. The authorised receivers decrypt the encrypted text payload using
the SEK and the relevant symmetric content encryption algorithm,
which was used to encrypt the payload.
Note that if an encrypted announcement is being announced via a proxy,
then there may be no way for the proxy to discover that the announcement
has been superseded, and so it may continue to relay the old
announcement in addition to the new announcement. SAP provides no
mechanism to chain modified encrypted announcements, so it is advisable
to announce the unmodified session as deleted for a short time after
the modification has occurred. This does not guarantee that all proxies
have deleted the session, and so receivers of encrypted sessions should
be prepared to discard old versions of session announcements that they
may receive (as identified by the SDP version field). In most cases
however, the only stateful proxy will be local to (and known to) the
sender, and an additional (local-area) protocol involving a handshake
for such session modifications can be used to avoid this problem.
Kirstein et al. [PAGE 8]
Internet Draft SIP Security March 12, 1998
3. Secured SAP Packet Formats
Both Authentication and Privacy can be achieved using PGP [2] or PKCS#7
[3] format packets. Implementers MUST support PGP format with support
for PKCS#7 being OPTIONAL. In Section 3.1 we discuss the generic packet
format defined in SAP [1]. In Section 3.2 we consider the formats of the
Authentication Header, and in Section 3.3 that of the encrypted payload.
It would be possible to define our own versions of the packets for this
application. In that case the formats would be simpler, but all the
implementations would have to be coded using the basic encryption
libraries, and a new infrastructure would have to be defined. Both PGP
and PKCS#7 already have complete implementations and, by using their
formats, several application tool kits are already available (e.g.
Entrust [14], Secude [15]). In addition, these formats also have
complete infrastructures defined around them. For these reasons, we have
chosen to retain enough compatibility to ease the eventual
implementation, while simplifying the formats as far as possible within
such a constraint. There is an additional advantage in this approach; it
will be possible to send session announcements by the encrypted Session
Invitation Protocol or by electronic mail using PGP or S-MIME, and
re-use much of the same code as with SAP.
3.1 Secured SAP Packet Format
The SAP data packets as defined in [1] has the following format:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=2 | MT |E|C| Header Length | 16 bit Message ID Hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Authentication Header (Optional) |
| .................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32 bit Time-Out Field (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Privacy Header (Optional) |
| .................. |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Text Payload (Possibly Encrypted) |
| .................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes:
Version Number, V: This is a 3-bit field and has the value 2 for this
version of SAP [1]
Message Type, MT: This defines the contents of the payload and can be
Kirstein et al. [PAGE 9]
Internet Draft SIP Security March 12, 1998
0. Session Descriptor Announcement Packet in which case the
payload is an SDP session description as described in [4]
1. Session Description Deletion Packet in which case the payload
is a singleSDP line containing the origin field of the
announcement to be deleted
Encryption Bit, E: -. If this is set, the text payload has been
encrypted
Compression Bit, C: If this is set the payload has been compressed using
the gzip compression utility [7]
Header length: This is an 8 bit unsigned quantity giving the number of
32 bit words following the main SAP header that contains the
authentication data. If this is non-zero, the payload is
authenticated, and an Authentication Header is present
Message Identifier Hash: This is a 16 bit quantity that, when used in
combination with the originating source, provides a globally unique
id identifying the precise version of this announcement. The message
id hash should be changed if any field of the session description is
changed. A value of zero means that the hash should be ignored and
the message should always be parsed.
Originating Source: This 32-bit field gives the IP address of the
original source of the message. It is permissible for this to be zero
if the message has not passed through a proxy relay and if the message
id hash is also zero. This is intended for backward compatibility with
SAPv0 clients only.
Authentication Header: This can be used for two purposes:
1. Verification that changes to a session description or deletion
of a session are permitted
2. Authentication of the identity of the session creator.
In some circumstances only verification is possible because a
certificate signed by a mutually trusted person or authority is not
available. However, under such circumstances, the session originator
can still be authenticated to be the same as the session originator of
previous sessions claiming to be from the same person. This may or may
not be sufficient, depending on the purpose of the session and the
people involved. The precise format of the Authentication Header is
discussed in Section 3.2.
Timeout: When the session payload is encrypted, and the session
description is being relayed or announced via a proxy, the detailed
timing fields in the SDP description are not available to the proxy.
This is because these fields are encrypted and the proxy is not
trusted with the decryption key. Under such circumstances, SAP
includes an additional 32-bit timestamp field stating when the session
should be timed out. The digital signature in the authentication
Kirstein et al. [PAGE 10]
Internet Draft SIP Security March 12, 1998
header encompasses the time-out so that a session cannot be
maliciously deleted by modifying its time-out in an announcing proxy.
The value is an unsigned quantity giving the NTP time [8] in seconds
at which time the session is timed out. It is in network byte order
and MUST be present when encryption has been used.
Privacy Header: This is present when the text payload has been encrypted
using hybrid encryption.
Text Payload: When there is no encryption, the encryption bit is not set
and this format is as defined in the SDP [4] draft. However, when
encryption has been used the payload is encrypted and the format is
discussed in Section 3.3.
3.2 Authentication Header
3.2.1 Generic Format
The generic format of the Authentication Header is given below. The
structure of the Format Specific Authentication Subheader, using both
the PGP and the PKCS#7 formats, is discussed in Sections 3.2.2 and 3.2.3
respectively.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=1 |P| Auth |SignatureLength| |
|+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+ |
| Format Specific Authentication Subheader |
| .................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes:
Version Number, V: For this release the version number is 1 (3 bits)
Padding Bit, P: If necessary the data in the Authentication Header is
padded to be a multiple of 32 bits and the Padding bit is set. In this
case the last byte of the Authentication Header contains the number of
padding bytes (including the last byte) that must be discarded.
Authentication Type, Auth: The Authentication Type is a 4 bit encoded
field that denotes the authentication infrastructure the sender
expects the recipients to use to check the authenticity and integrity
of the information. This defines the format of the Authentication
Subheader and can take the values:
1. PGP Format
2. PKCS#7 Format
3. PGP Format with the 'Certificate' included
4. PKCS#7 with the Certificate included
SignatureLength: This gives the length of the Signature. This is
necessary when the Authentication Type is 3 to allow the beginning of
Kirstein et al. [PAGE 11]
Internet Draft SIP Security March 12, 1998
the PGP Certificate packet to be found. In the PKCS#7 case (when the
Authentication type is 2 or 4) this is unnecessary and SHOULD be set
to zero.
3.2.2 PGP Format
Implementations MUST support this format.
The generic description of the PGP packets is presented in [2]. For PGP
the basic Format Specific Authentication Subheader comprises a digital
signature packet as described in [2]. This involves the use of a hash
code, or message digest algorithm, and a public key encryption
algorithm. The hash is taken of the text payload together with the
signature classification (1 byte) and signature time stamp (4 bytes)
fields as described in [2]. For the case when the Authentication type is
1 the Subheader contains a Digital Signature Packet only with the
hexadecimal signature classification being <00> or <01>. The only
Message Digest Algorithm is 1 (MD5) and the Public Key Cryptosystem
(PKC) is 1, this being the RSA system. If the type is 3 then a
Certificate Packet is also appended to the previous Signature Packet. A
certificate packet is composed of the following individual packets:
(a) A Public Key Packet which defines the RSA public key
(b) A UserID packet
(c) A Signature Packet
The Public Key packet again has the Public Key Cryptosystem 1. In the
case of Signature Packet (c) the signature classification now takes the
hexadecimal values <10> to <13>. These packets are all detailed in [2].
3.2.3 PKCS#7 Format
Support for this format is OPTIONAL.
The Format Specific Authentication Subheader will, in the PKCS#7 case,
have an ASN.1 ContentInfo type with the ContentType being signedData.
Use is made of the option available in PKCS#7 to leave the content
itself blank as the content which is signed is, in this application,
already present as the text payload, whether this is encrypted or not.
Thus inclusion of it within the SignedData type would be duplication and
increase the packet length unnecessarily. The full specification for
this ASN.1 type is available in [3].
There will only be one signerInfo and related fields corresponding to
the originator of the SAP announcement. Although it would be possible
to transfer the relevant information is a single signerInfo type rather
than the complete ContentInfo it is considered preferable to use the
latter for two reasons. Firstly, this is compatible with a wider range
of applications and security toolkits and secondly, that the certificate
can be included in a standard way. If the Authentication Type is 2 there
are no certificates or certificate revocation lists whereas if the
authentication type is 4 the originator's X.509 certificate is added in
the certificate field of this type.
Kirstein et al. [PAGE 12]
Internet Draft SIP Security March 12, 1998
In addition, for both type 2 and 4, use is made of the ability in PKCS#7
to authenticate various attributes as specified in PKCS#9 [16]. The
authenticatedAttributes field of the SignerInfo type is used and the
attribute which is authenticated is the SigningTime. This is a
mandatory field in this specification. Consequently, the initial input
to the message digesting process is the contents octets of the DER
encoding of the content field of the ContentInfo value (not including
the identifier octets or the length octets). Moreover, the signing time
is an authenticated attribute. Thus, the result of the message digest is
the complete DER encoding of the Attributes value contained in the
AuthenticatedAttributes field. This contains the SigningTime in addition
to the content type and message digest of the payload, which are
included automatically.
3.3 Encrypted Payload Format
3.3.1 Generic Format
The format of the Encrypted Payload depends on the type of encryption
used to encrypt the SDP text payload [4]. If no encryption has been used
only the Text payload is present.
If encryption has been used then the encryption bit in the main SAP
header is set and the payload is encrypted either symmetrically or
using hybrid encryption. For symmetric encryption the format is detailed
in Section 3.3.2 whereas hybrid encryption is detailed in Section 3.3.3.
For hybrid encryption there are two possibilities - PGP and PKCS#7
Formats. The application is expected to test whether the fields
immediately following the timeout field in the main SAP header is
compatible with the use of symmetric encryption; in this case it will be
a padding bit followed by a 31-bit random field, or whether it is
compatible with the use of hybrid encryption. In this case there is a
very specific format to the first byte of the Privacy header, which
follows other time-out field in this case.
3.3.2 Symmetric Encryption
If symmetric encryption alone has been used then the encrypted payload
has a random field added prior to encryption as below.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| 31 bit random field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Text Payload |
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes
Random Field: This field is only present when payload is encrypted
using symmetric encryption and is used to perform the randomisation
Kirstein et al. [PAGE 13]
Internet Draft SIP Security March 12, 1998
tasks normally performed by an initialisation vector in algorithms
such as DES. This 31-bit field should contain a genuinely random
number.
Padding Bit, P: This bit indicates that the payload was padded prior to
encryption. The last byte of the encrypted payload indicates how many
padding bytes were added.
The data following the Time-out field is decrypted using the algorithm
specified above. Further details on the encryption algorithms are given
in [6, 12, 13].
3.3.3 Hybrid Encryption
If a combination of asymmetric and symmetric encryption has been used
then the part of the SAP packet following the time-out field has the
following structure. This effectively takes the form of a Privacy header
followed by the encrypted SDP payload, the precise format depending on
whether PGP or PKCS#7 formats have been used. The specific details for
each of these formats are described in Sections 3.3.3.1 and 3.3.3.2
respectively and, as with authentication, implementations MUST support
PGP with PKCS#7 being OPTIONAL.
Privacy Header:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=1 |P| Type | Header Length | |
|+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+ |
| Format Specific Privacy Subheader |
| .................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes:
Version, V: In this version the Version of the privacy Header is 1
Padding Bit, P: If necessary the data in the Privacy Header is padded to
be a multiple of 32 bits and the Padding bit is set. In this case the
last byte of the Privacy Header contains the number of padding bytes
(including the last byte) that must be discarded.
Format Type, Type: This can be either 1 for PGP or 2 for PKCS#7 format.
Header Length: This gives the length of the Privacy Header.
3.3.3.1 PGP Format Privacy Header
For the case when the Format Type is 1 the Format Specific Privacy
Subheader is composed of a PGP Public Key encrypted packet and the text
payload is a PGP Conventional Key Encrypted Packet. These are detailed
in [2]. The Public Key Cryptosystem is 1, this being defined as the RSA
system, and the only supported symmetric encryption algorithm is the
Kirstein et al. [PAGE 14]
Internet Draft SIP Security March 12, 1998
IDEA algorithm, corresponding to the Conventional encryption type byte
value of 1.
3.3.3.2 PKCS#7 Format Privacy Header
If the Type is 2 then the Format Specific Privacy Header is composed of
a PKCS#7 ContentInfo type with the ContentType being envelopedData.
These are detailed in [2]. In this case the Text Payload, which has been
symmetrically encrypted with the algorithm specified in the
contentEncryptionAlgorithm field, is effectively the encryptedContent
part of the structure. There will be only one recipientInfo structure
corresponding to the group certificate, which has been previously
distributed. The contentType in the EncryptedContentInfo structure is
"Data".
3.3.4 Supported Algorithms
It is the policy of the IESG that unencumbered algorithms should be used
wherever possible. The only encumbered algorithm mandatory in the section
below is RSA; we understand that arrangements are being made to avoid
licence fees on this algorithm. At present implementations of suitable
unencumbered algorithms are not readily available.
3.3.4.1 Symmetric Encryption
If symmetric encryption alone is used then DES [6] MUST be supported.
3.3.4.2 Hybrid Encryption
3.3.4.2.1 PGP Format
- Content Encryption - the IDEA symmetric encryption algorithm with
a key length of 128 bits MUST be supported.
- Digest Algorithm - the MD5 [18] Message Digest Algorithm MUST be
supported.
- Digest Encryption Algorithm - the asymmetric rsaEncryption algorithm
[10] MUST be supported with key sizes from 512 bits to 1024 bits.
- Key encryption Algorithm - the asymmetric rsaEncryption algorithm
[10] MUST be supported with key sizes from 512 bits to 1024 bits.
3.3.4.2.2 PKCS#7 Format
In order to maintain wide interoperability the algorithms supported
here follow [23] where fuller details can be found.
- KeyEncryptionAlgorithmIdentifier
Sending and receiving agents MUST support Diffie-Hellman defined
in [21].
Kirstein et al. [PAGE 15]
Internet Draft SIP Security March 12, 1998
Receiving agents SHOULD support rsaEncryption [10]. 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.
- SignatureAlgorithmIdentifier
Sending and receiving agents MUST support id-dsa defined in
[22]. The algorithm parameters MUST be absent (not encoded as
NULL).
Receiving agents SHOULD support rsaEncryption, defined in [10].
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.
- ContentEncryptionAlgorithmIdentifier
Receiving agents MUST support encryption and decryption with
DES EDE3 CBC [17]. Receiving agents SHOULD support encryption
and decryption using the RC2 [20] or a compatible algorithm at
a key size of 40 bits.
- DigestAlgorithmIdentifier
Receiving agents MUST support SHA-1 [19]. Receiving agents
SHOULD support MD5 [27].
Sending agents SHOULD use SHA-1.
4 Changes From Previous Draft
Section 2.2 has been rewritten and there have been other minor changes
to the text. A table of contents has been added and a "Signature Length"
field added to the Authentication Header to allow access to the PGP
Certificate when the authentication type is 3. Support for PGP is now
specified as MANDATORY with support for PKCS#7 being OPTIONAL.
Kirstein et al. [PAGE 16]
Internet Draft SIP Security March 12, 1998
References
[1] M.Handley `SAP: Session Announcement Protocol'' INTERNET-DRAFT,
draft-ietf-mmusic-sap-00.txt, 11/27/1996.
[2] D.Atkins, '' PGP Message Exchange Formats'' ,
RFC 1991, August 1996.
[3] PKCS#7, Cryptographic Message Syntax Standard, RSA Laboratories,
Version 1.5, November 1993
[4] M.Handley, V. Jacobson, ``SDP: Session Description Protocol'',
INTERNET-DRAFT, draft-ietf-mmusic-sdp-02.txt, 11/27/1996.
[5] R. Housley , W. Ford , T. Polk Internet Public Key Infrastructure
INTERNET- DRAFT, draft-ietf-pkix-ipki-part1-03.txt December 1996.
[6] National Bureau of Standards, Data Encryption Standard, Federal
Information Processing Standards Publication 46, January 1977
[7] P. Deutsch, ``GZIP file format specification version 4.3'',
RFC 1952, May 1996.
[8] D. Mills, ``Network Time Protocol version 2 specification and
implementation", RFC1119, 1st Sept 1989.
[9] X.208 Specification of Abstract Syntax Notation One (ASN.1)
ITU-T Recommendations 1988
[10] PKCS #1 RSA Encryption Standard RSA Laboratories, Version 1.5,
November 1993
[11] H. Schulzrinne, ``RTP Profile for Audio and Video Conferences with
Minimal Control'', RFC 1890, January 1996
[12] P. Metzger, P. Karn, W. Simpson, The ESP Information Triple
DES-CBC Transformation, 10/02/1995 RFC850
[13] ANSI X3.92-1981. American National Standards Data Encryption
Algorithm. American National Standards Institute,
Approved 30 December 1990
[14] For details of ENTRUST see http://www.entrust.com/
[15] For details of SECUDE see http://www.darmstadt.gmd.de/secude/
[16] PKCS#9 Selected Attribute Types,
RSA Laboratories, Version 1.1, November 1993
[17] W. Tuchman, "Hellman Presents No Shortcut Solutions to DES"
IEEE Spectrum, v. 16, n. 7, July 1979, pp 40-41
[18] "The MD5 Message Digest Algorithm" RFC 1321
Kirstein et al. [PAGE 17]
Internet Draft SIP Security March 12, 1998
[19] NIST FIPS PUB 180-1 "Secure Hash Standard"
National Institute of Standards and Technology,
U.S. Department of Commerce, DRAFT, 31
[20] "Description of the RC2 Encryption Algorithm",
Internet Draft draft-rivest-rc2desc.
[21] ANSI X9.42
[22] ANSI X9.57-1997x,
"Public Key Cryptography for the Financial Services Industry:
Certificate Management". Working Draft, June 1996
[23] B. Ramsdell "S/MIME Version 3 Message Specification"
Internet Draft: draft-ietf-smime-msg-01.txt, Jan 1998
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
SAP and SDP were originally based on the protocol used by the sd session
directory from Van Jacobson at LBNL. The European Commission under the
Esprit 7602 "MICE" project, the Telematics 1007 "MERCI" project and the
Telematics 1005 "ICE-TEL" project funded the design of SAP and SAP
Security.
Kirstein et al. [PAGE 18]