draft-ietf-mmusic-sap-sec-03.txt   draft-ietf-mmusic-sap-sec-04.txt 
Internet Engineering Task Force MMUSIC WG Internet Engineering Task Force MMUSIC WG
Internet Draft P. Kirstein Internet Draft P. Kirstein
draft-ietf-mmusic-sap-sec-03.txt G. Montasser-Kohsari draft-ietf-mmusic-sap-sec-04.txt G. Montasser-Kohsari
November 1st 1997 E. Whelan March 12th 1998 E. Whelan
Expires: May 1st 1998 University College London Expires: September 12th 1998 University College London
Specification of Security in SAP Using Public Key Algorithms SAP Security Using Public Key Algorithms
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at line 73 skipping to change at line 73
PKCS Public Key Cryptographic System PKCS Public Key Cryptographic System
PKCS Public Key Cryptography Standard (as in PKCS#7) PKCS Public Key Cryptography Standard (as in PKCS#7)
SAP Session Announcement Protocol SAP Session Announcement Protocol
SDP Session Descriptor Protocol SDP Session Descriptor Protocol
SEK Session Encryption Key SEK Session Encryption Key
SK Secret Key SK Secret Key
SGK Group Key SGK Group Key
SHA Hash Algorithm SHA Hash Algorithm
Kirstein et al. [PAGE 2] Kirstein et al. [PAGE 2]
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]
1. Introduction 1. Introduction
An Mbone session directory is used to advertise multimedia conferences, An Mbone session directory is used to advertise multimedia conferences,
and to communicate the session addresses (whether multicast or unicast) and to communicate the session addresses (whether multicast or unicast)
and conference-tool- specific information necessary for participation. and conference-tool- specific information necessary for participation.
Such sessions are be announced using the Session Announcement Protocol Such sessions are be announced using the Session Announcement Protocol
(SAP) described in a companion draft [1]. The SAP protocol allows for (SAP) described in a companion draft [1]. The SAP protocol allows for
the incorporation of authentication of the announcement originator, and the incorporation of authentication of the announcement originator, and
for privacy of the session details; however neither the choice of for privacy of the session details; however neither the choice of
authentication algorithms used, nor the mechanisms for encrypting the authentication algorithms used, nor the mechanisms for encrypting the
SAP Session Description, are detailed in the draft. SDP Session Description, are detailed in the draft.
This document describes the format of the authentication header for SAP 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]. data packets that use security services based on PGP [2] or PKCS#7 [3].
The SAP document also provides for the confidentiality services required The SAP document also provides for the confidentiality services required
for the SDP payload [4], which describes the conference set-up for the SDP payload [4], which describes the conference set-up
parameters. This document describes how both symmetric and hybrid parameters. This document describes how both symmetric and hybrid
symmetric/public key encryption algorithms should be used to provide symmetric/public key encryption algorithms should be used to provide
private announcements. private announcements.
Much of this document is concerned with security considerations. This Much of this document is concerned with security considerations. This
skipping to change at line 121 skipping to change at line 159
there are a number of threats which we must try to address in the there are a number of threats which we must try to address in the
securing of the Session Announcement, and some constraints. These securing of the Session Announcement, and some constraints. These
include the following: include the following:
- Authentication and Integrity of Session Announcement - Authentication and Integrity of Session Announcement
Here it is necessary to ensure that the Session Announcement comes from Here it is necessary to ensure that the Session Announcement comes from
the person claimed, and is indeed an authorised announcement. Since the person claimed, and is indeed an authorised announcement. Since
subsequent announcements will modify caches of future conferences, it is subsequent announcements will modify caches of future conferences, it is
possible otherwise to spoof an original announcement, and thereby at possible otherwise to spoof an original announcement, and thereby at
least cause a Denial of Service attack least cause a Denial of Service attack.
- Confidentiality of Conference Details for Session Announcement - Confidentiality of Conference Details for Session Announcement
Here it is at least necessary to hide the details of the addresses and 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 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 desirable to keep at least the time of a conference known, even if all
Kirstein et al. [PAGE 3] Kirstein et al. [PAGE 4]
other details are concealed. other details are concealed.
Three types of announcement are supported: 'unsecured', 'authenticated' Three types of announcement are supported: 'unsecured', 'authenticated'
and 'authenticated and encrypted'. The 'unsecured' type is described in and 'authenticated and encrypted'. The 'unsecured' type is described in
the SAP specification [1] and so only the latter two types are described the SAP specification [1] and so only the latter two types are described
below. below.
2.2 Symmetric and Asymmetric Encryption 2.2 Symmetric and Asymmetric Encryption
The simplest versions of encryption used are symmetric ones; here the The simplest versions of encryption are symmetric ones; here the
same encryption key 'a' is used to encrypt and decrypt a message. This encryption key can be calculated from the decryption key and vice versa.
means that, if E{a,M) is the operation of encrypting the message M with In most cases the encryption key and decryption key are the same. This
the key a and algorithm E, then the operation E{a, E{a, M}} reproduces means that, if E{a,M} is the operation of encrypting the message M with
the original message M. Because this form of encryption relies on the the key a and algorithm E, then the decryption operation D{a, E{a, M}}
sender and receiver having the same key, it cannot be used for reproduces the original message M. If several people know the key then
authentication. An alternative form of encryption is asymmetric symmetric encryption cannot be used for authentication.
encryption. Here two keys, a and b, are used. When these are used one
after the other to encrypt a message the original message is obtained.
Mathematically, these keys and the encryption algorithm E have the
property that E{a, E{b, M}} and E{b, E{a, M}} both produce the original
message M - but given a, it should be impractical to deduce b and
vice versa.
With an asymmetric encryption algorithm, a Public Key Cryptographic An alternative form of encryption is with the use of asymmetric
System (PKCS) can be derived in which one of the keys, say the Public algorithms (also known as Public Key algorithms). Here the key used for
Key (PK), is published in some way while the other, the Secret Key (SK), encryption is different to that used for decryption and it is not
is kept secret. Using such a PKCS, it is possible to achieve both feasible to calculate one from the other. Consequently the encryption
confidentiality and authentication. Encrypting a message with the key can be made public and is known as the Public Key. Encrypting a
recipient's Public Key ensures confidentiality as only the recipient message with the recipient's Public Key ensures confidentiality as only
with the corresponding SK can decrypt the message. Encrypting a message the recipient with the corresponding decryption key (known as the
with the SK of the sender ensures authentication as only the sender Private Key) can decrypt the message. Encrypting a message with the
could have sent the message initially whereas anybody having access to Private Key of the sender ensures authentication as only the sender
the Public Key can verify that it was indeed sent by the person holding could have sent the message whereas anybody having access to the Public
the corresponding Secret Key. 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 Two complete systems, which can achieve both authentication and
confidentiality using particular PKCS systems, are PGP [2] and PKCS#7 confidentiality using particular PKCS systems, are PGP [2] and PKCS#7
[3]; similar mechanisms are used, but different encryption algorithms [3]; similar mechanisms are used, but different encryption algorithms
and formats are used. The differences between the algorithm and format 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. 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 2.3 Authenticated Announcements
In order to send authenticated announcements it is possible to use the 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 algorithms of either PGP [2] or the PKCS#7 [3] systems. The resulting
format will be substantially different; the exact details are given in format will be substantially different; the exact details are given in
Kirstein et al. [PAGE 5]
Sections 3.2 and 3.3. For each format, the announcement originator Sections 3.2 and 3.3. For each format, the announcement originator
calculates a message digest of the announcement. The originator's calculates a message digest of the announcement. The originator's
secret key is used to encrypt the message digest, together with an secret key is used to encrypt the message digest, together with an
electronic timestamp, thus forming a digital signature. The originator electronic timestamp, thus forming a digital signature. The originator
sends the digital signature along with the message; the receiver sends the digital signature along with the message; the receiver
receives the message and the digital signature, and recovers the receives the message and the digital signature, and recovers the
original message digest from the digital signature by decrypting it original message digest from the digital signature by decrypting it
with the sender's public key. The receiver computes a new message with the sender's public key. The receiver computes a new message
Kirstein et al. [PAGE 4]
digest from the message, and checks to see if it matches the one digest from the message, and checks to see if it matches the one
recovered from the digital signature. If it matches, then this is recovered from the digital signature. If it matches, then this is
considered adequate proof that the message was not altered, and that it 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 came from the originator who owns the public key used to check the
signature. signature.
Each Session announcement contains a message ID hash [4]. The Each Session announcement contains a message ID hash [4]. The
specifications for SAP announcements [1] states that such announcements specifications for SAP announcements [1] states that such announcements
may be repeated frequently, but that if any change is made in the 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 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, 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 it is only necessary to authenticate an announcement the first time it
is received. is received.
To save space in the announcement message, only a public key identifier To save space in the announcement message, only a public key identifier
is generally included. It is then assumed that the public key itself is generally included. It is then assumed that the public key itself
has either been distributed previously or can be retrieved from a cache has either been distributed previously or can be retrieved from a cache
or directory. Optionally the Public Key itself can be included in the or directory. Optionally the Public Key itself can be included in the
announcement removing the need for prior distribution. Consequently, announcement in the form of a certificate removing the need for prior
providing that the Public Key is already available in a local cache or distribution. Consequently, providing that the Public Key is already
Directory, or is distributed with the announcement, one can be sure that available in a local cache or Directory, or is distributed with the
the same originator sent the announcement. Only if the full public key announcement, one can be sure that the same originator sent the
information, and a Certificate Authority infrastructure, are accessible announcement. Only if the full public key information, and a Certificate
[5], can the originator be identified. Authority infrastructure, are accessible, can the originator be
identified [5].
2.4 Authenticated and Encrypted Announcements 2.4 Authenticated and Encrypted Announcements
2.4.1 Introduction 2.4.1 Introduction
When it is desired to make private announcements, it is necessary to When it is desired to make private announcements, it is necessary to
encrypt the set-up details of the conference. The normal way of encrypt the set-up details of the conference. The normal way of
providing such encryption is to use only a symmetric encryption providing such encryption is to use only a symmetric encryption
algorithm such as the Data Encryption Standard (DES [6]) to encrypt algorithm such as the Data Encryption Standard (DES [6]) to encrypt
such a session using a Session Encryption Key (SEK); this algorithm is such a session using a Session Encryption Key (SEK); this algorithm is
skipping to change at line 234 skipping to change at line 281
economic for smaller amounts. For symmetric encryption systems, the SEK economic for smaller amounts. For symmetric encryption systems, the SEK
must be securely distributed to all authorised recipients. must be securely distributed to all authorised recipients.
2.4.2 Distribution of Session Encryption Keys 2.4.2 Distribution of Session Encryption Keys
There are various ways that the SEK could be distributed; all rely on There are various ways that the SEK could be distributed; all rely on
distributing some shared secret in advance to the intended participants distributing some shared secret in advance to the intended participants
in the conference group. When this process takes place out of band, it in the conference group. When this process takes place out of band, it
is not described further in this document. is not described further in this document.
Kirstein et al. [PAGE 6]
Many symmetric encryption algorithms, e.g. DES [6] are known to be easy 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 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 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 distributed out-of-band; the recipients may then try to decrypt the
announcement by trying each of these SEKs in turn. 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 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 the announcement, a different message ID, and hence message ID hash is
Kirstein et al. [PAGE 5]
used; it is only necessary to attempt to decrypt an announcement message used; it is only necessary to attempt to decrypt an announcement message
the first time it is received. The basic symmetric system is contained the first time it is received. The basic symmetric system is contained
in SAP [1]. To improve efficiency, it would be possible to use in SAP [1]. To improve efficiency, it would be possible to use
symmetric encryption with a pre-distributed Key Identifier (KeyID). symmetric encryption with a pre-distributed Key Identifier (KeyID).
However, because of the potential weakening of the security by the use However, because of the potential weakening of the security by the use
of KeyIDs, and the consequent need to use more secure symmetric of KeyIDs, and the consequent need to use more secure symmetric
algorithms, we do not recommend this technique. Moreover, by adopting algorithms, we do not recommend this technique. Moreover, by adopting
the use of asymmetric Public Key technology for such SEK distribution as the use of asymmetric Public Key technology for such SEK distribution as
discussed below, we gain both efficiency and have a better integrated discussed below, we gain both efficiency and have a better integrated
approach to authentication. approach to authentication.
skipping to change at line 289 skipping to change at line 335
group which has reserved the asymmetric encryption key pair. It is group which has reserved the asymmetric encryption key pair. It is
still possible to authenticate the identity of the sender by using a still possible to authenticate the identity of the sender by using a
different Authentication Key for the Authentication Header as described different Authentication Key for the Authentication Header as described
in Section 2.3. in Section 2.3.
It would be possible to use a similar technique using symmetric It would be possible to use a similar technique using symmetric
encryption with a strong encryption algorithm and an encryption key encryption with a strong encryption algorithm and an encryption key
Identifier instead of the Public Key Group Key, However, we believe the Identifier instead of the Public Key Group Key, However, we believe the
Public Key method to be superior so this variant is not pursued. Public Key method to be superior so this variant is not pursued.
Kirstein et al. [PAGE 7]
2.4.4 Encrypting Announcements 2.4.4 Encrypting Announcements
We will now provide some more detail. If the payload is to be We will now provide some more detail. If the payload is to be
compressed, this is performed prior to encryption. 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 When an announcement is to be encrypted, the payload is encrypted using
symmetric encryption. In this case each such encryption key is used only 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 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 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 bound to the message and transmitted with it in a Privacy Header. The
Kirstein et al. [PAGE 6]
sequence is as follows: The Privacy Header contains the SEK, encrypted sequence is as follows: The Privacy Header contains the SEK, encrypted
with the group's Public Group Key, together with information identifying 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 Group Key which has been used. The encrypted Payload is appended to
the Privacy Header. the Privacy Header.
2.4.5 Decrypting Announcements 2.4.5 Decrypting Announcements
Upon receiving a new announcement with the encryption bit set, a Upon receiving a new announcement with the encryption bit set, a
receiver should attempt to decrypt the announcement with the relevant receiver should attempt to decrypt the announcement with the relevant
group private key or their own private key as indicated in the Privacy group private key or their own private key as indicated in the Privacy
skipping to change at line 344 skipping to change at line 390
mechanism to chain modified encrypted announcements, so it is advisable mechanism to chain modified encrypted announcements, so it is advisable
to announce the unmodified session as deleted for a short time after to announce the unmodified session as deleted for a short time after
the modification has occurred. This does not guarantee that all proxies the modification has occurred. This does not guarantee that all proxies
have deleted the session, and so receivers of encrypted sessions should have deleted the session, and so receivers of encrypted sessions should
be prepared to discard old versions of session announcements that they be prepared to discard old versions of session announcements that they
may receive (as identified by the SDP version field). In most cases 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 however, the only stateful proxy will be local to (and known to) the
sender, and an additional (local-area) protocol involving a handshake sender, and an additional (local-area) protocol involving a handshake
for such session modifications can be used to avoid this problem. for such session modifications can be used to avoid this problem.
Kirstein et al. [PAGE 8]
3. Secured SAP Packet Formats 3. Secured SAP Packet Formats
Both Authentication and Privacy can be achieved using PGP [2] or PKCS#7 Both Authentication and Privacy can be achieved using PGP [2] or PKCS#7
[3] format packets. In Section 3.1 we discuss the generic packet format [3] format packets. Implementers MUST support PGP format with support
defined in SAP [1]. In Section 3.2 we consider the formats of the 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. 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 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 application. In that case the formats would be simpler, but all the
implementations would have to be coded using the basic encryption implementations would have to be coded using the basic encryption
libraries, and a new infrastructure would have to be defined. Both PGP libraries, and a new infrastructure would have to be defined. Both PGP
and PKCS#7 already have complete implementations and, by using their and PKCS#7 already have complete implementations and, by using their
Kirstein et al. [PAGE 7]
formats, several application tool kits are already available (e.g. formats, several application tool kits are already available (e.g.
Entrust [14], Secude [15]). In addition, these formats also have Entrust [14], Secude [15]). In addition, these formats also have
complete infrastructures defined around them. For these reasons, we have complete infrastructures defined around them. For these reasons, we have
chosen to retain enough compatibility to ease the eventual chosen to retain enough compatibility to ease the eventual
implementation, while simplifying the formats as far as possible within implementation, while simplifying the formats as far as possible within
such a constraint. There is an additional advantage in this approach; it such a constraint. There is an additional advantage in this approach; it
will be possible to send session announcements by the encrypted Session will be possible to send session announcements by the encrypted Session
Invitation Protocol or by electronic mail using PGP or S-MIME, and Invitation Protocol or by electronic mail using PGP or S-MIME, and
re-use much of the same code as with SAP. re-use much of the same code as with SAP.
skipping to change at line 399 skipping to change at line 445
| .................. | | .................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes: Notes:
Version Number, V: This is a 3-bit field and has the value 2 for this Version Number, V: This is a 3-bit field and has the value 2 for this
version of SAP [1] version of SAP [1]
Message Type, MT: This defines the contents of the payload and can be Message Type, MT: This defines the contents of the payload and can be
Kirstein et al. [PAGE 9]
0. Session Descriptor Announcement Packet in which case the 0. Session Descriptor Announcement Packet in which case the
payload is an SDP session description as described in [4] payload is an SDP session description as described in [4]
1. Session Description Deletion Packet in which case the payload 1. Session Description Deletion Packet in which case the payload
is a singleSDP line containing the origin field of the is a singleSDP line containing the origin field of the
announcement to be deleted announcement to be deleted
Encryption Bit, E: -. If this is set, the text payload has been Encryption Bit, E: -. If this is set, the text payload has been
encrypted encrypted
Compression Bit, C: If this is set the payload has been compressed using Compression Bit, C: If this is set the payload has been compressed using
the gzip compression utility [7] the gzip compression utility [7]
Kirstein et al. [PAGE 8]
Header length: This is an 8 bit unsigned quantity giving the number of Header length: This is an 8 bit unsigned quantity giving the number of
32 bit words following the main SAP header that contains the 32 bit words following the main SAP header that contains the
authentication data. If this is non-zero, the payload is authentication data. If this is non-zero, the payload is
authenticated, and an Authentication Header is present authenticated, and an Authentication Header is present
Message Identifier Hash: This is a 16 bit quantity that, when used in Message Identifier Hash: This is a 16 bit quantity that, when used in
combination with the originating source, provides a globally unique combination with the originating source, provides a globally unique
id identifying the precise version of this announcement. The message id identifying the precise version of this announcement. The message
id hash should be changed if any field of the session description is 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 changed. A value of zero means that the hash should be ignored and
skipping to change at line 455 skipping to change at line 500
people involved. The precise format of the Authentication Header is people involved. The precise format of the Authentication Header is
discussed in Section 3.2. discussed in Section 3.2.
Timeout: When the session payload is encrypted, and the session Timeout: When the session payload is encrypted, and the session
description is being relayed or announced via a proxy, the detailed description is being relayed or announced via a proxy, the detailed
timing fields in the SDP description are not available to the proxy. timing fields in the SDP description are not available to the proxy.
This is because these fields are encrypted and the proxy is not This is because these fields are encrypted and the proxy is not
trusted with the decryption key. Under such circumstances, SAP trusted with the decryption key. Under such circumstances, SAP
includes an additional 32-bit timestamp field stating when the session includes an additional 32-bit timestamp field stating when the session
should be timed out. The digital signature in the authentication should be timed out. The digital signature in the authentication
Kirstein et al. [PAGE 10]
header encompasses the time-out so that a session cannot be header encompasses the time-out so that a session cannot be
maliciously deleted by modifying its time-out in an announcing proxy. maliciously deleted by modifying its time-out in an announcing proxy.
The value is an unsigned quantity giving the NTP time [8] in seconds 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 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 Privacy Header: This is present when the text payload has been encrypted
using hybrid encryption. using hybrid encryption.
Text Payload: When there is no encryption, the encryption bit is not set 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 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 encryption has been used the payload is encrypted and the format is
discussed in Section 3.3. discussed in Section 3.3.
Kirstein et al. [PAGE 9]
3.2 Authentication Header 3.2 Authentication Header
3.2.1 Generic Format 3.2.1 Generic Format
The generic format of the Authentication Header is given below. The The generic format of the Authentication Header is given below. The
structure of the Format Specific Authentication Subheader, using both 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 the PGP and the PKCS#7 formats, is discussed in Sections 3.2.2 and 3.2.3
respectively. respectively.
1 2 3 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 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 | Header Length | | | V=1 |P| Auth |SignatureLength| |
|+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+ | |+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+ |
| Format Specific Authentication Subheader | | Format Specific Authentication Subheader |
| .................. | | .................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes: Notes:
Version Number, V: For this release the version number is 1 (3 bits) 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 Padding Bit, P: If necessary the data in the Authentication Header is
skipping to change at line 508 skipping to change at line 554
field that denotes the authentication infrastructure the sender field that denotes the authentication infrastructure the sender
expects the recipients to use to check the authenticity and integrity expects the recipients to use to check the authenticity and integrity
of the information. This defines the format of the Authentication of the information. This defines the format of the Authentication
Subheader and can take the values: Subheader and can take the values:
1. PGP Format 1. PGP Format
2. PKCS#7 Format 2. PKCS#7 Format
3. PGP Format with the 'Certificate' included 3. PGP Format with the 'Certificate' included
4. PKCS#7 with the Certificate included 4. PKCS#7 with the Certificate included
Header Length: This gives the length of the Authentication Header. 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]
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 3.2.2 PGP Format
Implementations MUST support this format.
The generic description of the PGP packets is presented in [2]. For PGP The generic description of the PGP packets is presented in [2]. For PGP
the basic Format Specific Authentication Subheader comprises a digital the basic Format Specific Authentication Subheader comprises a digital
signature packet as described in [2]. This involves the use of a hash signature packet as described in [2]. This involves the use of a hash
code, or message digest algorithm, and a public key encryption algorithm. code, or message digest algorithm, and a public key encryption
The hash is taken of the text payload together with the signature algorithm. The hash is taken of the text payload together with the
classification (1 byte) and signature time stamp (4 bytes) fields as signature classification (1 byte) and signature time stamp (4 bytes)
described in [2]. For the case when the Authentication type is 1 the fields as described in [2]. For the case when the Authentication type is
Subheader contains a Digital Signature Packet only with the hexadecimal 1 the Subheader contains a Digital Signature Packet only with the
signature classification being <00> or <01>. The only Message Digest hexadecimal signature classification being <00> or <01>. The only
Algorithm is 1 (MD5) and the Public Key Cryptosystem (PKC) is 1, this Message Digest Algorithm is 1 (MD5) and the Public Key Cryptosystem
being the RSA system. If the type is 3 then a Certificate Packet is also (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
Kirstein et al. [PAGE 10] certificate packet is composed of the following individual packets:
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 (a) A Public Key Packet which defines the RSA public key
(b) A UserID packet (b) A UserID packet
(c) A Signature Packet (c) A Signature Packet
The Public Key packet again has the Public Key Cryptosystem 1. In the The Public Key packet again has the Public Key Cryptosystem 1. In the
case of Signature Packet (c) the signature classification now takes the case of Signature Packet (c) the signature classification now takes the
hexadecimal values <10> to <13>. These packets are all detailed in [2]. hexadecimal values <10> to <13>. These packets are all detailed in [2].
3.2.3 PKCS#7 Format 3.2.3 PKCS#7 Format
Support for this format is OPTIONAL.
The Format Specific Authentication Subheader will, in the PKCS#7 case, The Format Specific Authentication Subheader will, in the PKCS#7 case,
have an ASN.1 ContentInfo type with the ContentType being signedData. 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 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, itself blank as the content which is signed is, in this application,
already present as the text payload, whether this is encrypted or not. already present as the text payload, whether this is encrypted or not.
Thus inclusion of it within the SignedData type would be duplication and Thus inclusion of it within the SignedData type would be duplication and
increase the packet length unnecessarily. The full specification for increase the packet length unnecessarily. The full specification for
this ASN.1 type is available in [3]. this ASN.1 type is available in [3].
There will only be one signerInfo and related fields corresponding to There will only be one signerInfo and related fields corresponding to
the originator of the SAP announcement. Although it would be possible the originator of the SAP announcement. Although it would be possible
to transfer the relevant information is a single signerInfo type rather to transfer the relevant information is a single signerInfo type rather
than the complete ContentInfo it is considered preferable to use the than the complete ContentInfo it is considered preferable to use the
latter for two reasons. Firstly, this is compatible with a wider range latter for two reasons. Firstly, this is compatible with a wider range
of applications and security toolkits and secondly, that the certificate of applications and security toolkits and secondly, that the certificate
can be included in a standard way. If the Authentication Type is 2 there can be included in a standard way. If the Authentication Type is 2 there
are no certificates or certificate revocation lists whereas if the are no certificates or certificate revocation lists whereas if the
authentication type is 4 the originator's X.509 certificate is added in authentication type is 4 the originator's X.509 certificate is added in
the certificate field of this type. the certificate field of this type.
Kirstein et al. [PAGE 12]
In addition, for both type 2 and 4, use is made of the ability in PKCS#7 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 to authenticate various attributes as specified in PKCS#9 [16]. The
authenticatedAttributes field of the SignerInfo type is used and the authenticatedAttributes field of the SignerInfo type is used and the
attribute which is authenticated is the SigningTime. This is a attribute which is authenticated is the SigningTime. This is a
mandatory field in this specification. Consequently, the initial input to mandatory field in this specification. Consequently, the initial input
the message digesting process is the contents octets of the DER encoding to the message digesting process is the contents octets of the DER
of the content field of the ContentInfo value (not including the encoding of the content field of the ContentInfo value (not including
identifier octets or the length octets). Moreover, the signing time is an the identifier octets or the length octets). Moreover, the signing time
authenticated attribute. Thus, the result of the message digest is the is an authenticated attribute. Thus, the result of the message digest is
complete DER encoding of the Attributes value contained in the the complete DER encoding of the Attributes value contained in the
AuthenticatedAttributes field. This contains the SigningTime in addition AuthenticatedAttributes field. This contains the SigningTime in addition
to the content type and message digest of the payload, which are included to the content type and message digest of the payload, which are
automatically. included automatically.
3.3 Encrypted Payload Format 3.3 Encrypted Payload Format
3.3.1 Generic Format 3.3.1 Generic Format
The format of the Encrypted Payload depends on the type of encryption 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 used to encrypt the SDP text payload [4]. If no encryption has been used
only the Text payload is present. only the Text payload is present.
Kirstein et al. [PAGE 11]
If encryption has been used then the encryption bit in the main SAP If encryption has been used then the encryption bit in the main SAP
header is set and the payload is encrypted either symmetrically or header is set and the payload is encrypted either symmetrically or
using hybrid encryption. For symmetric encryption the format is detailed 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. 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 For hybrid encryption there are two possibilities - PGP and PKCS#7
Formats. The application is expected to test whether the fields Formats. The application is expected to test whether the fields
immediately following the timeout field in the main SAP header is immediately following the timeout field in the main SAP header is
compatible with the use of symmetric encryption; in that case it will be 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 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 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 very specific format to the first byte of the Privacy header, which
follows other time-out field in this case. follows other time-out field in this case.
3.3.2 Symmetric Encryption 3.3.2 Symmetric Encryption
If symmetric encryption alone has been used then the encrypted payload If symmetric encryption alone has been used then the encrypted payload
has a random field added prior to encryption as below. has a random field added prior to encryption as below.
skipping to change at line 614 skipping to change at line 667
|P| 31 bit random field | |P| 31 bit random field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Text Payload | | Text Payload |
| . . . | | . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes Notes
Random Field: This field is only present when payload is encrypted Random Field: This field is only present when payload is encrypted
using symmetric encryption and is used to perform the randomisation using symmetric encryption and is used to perform the randomisation
Kirstein et al. [PAGE 13]
tasks normally performed by an initialisation vector in algorithms tasks normally performed by an initialisation vector in algorithms
such as DES. This 31-bit field should contain a genuinely random such as DES. This 31-bit field should contain a genuinely random
number. number.
Padding Bit, P: This bit indicates that the payload was padded prior to Padding Bit, P: This bit indicates that the payload was padded prior to
encryption. The last byte of the encrypted payload indicates how many encryption. The last byte of the encrypted payload indicates how many
padding bytes were added. padding bytes were added.
The data following the Time-out field is decrypted using the algorithm The data following the Time-out field is decrypted using the algorithm
specified above. Further details on the encryption algorithms are given specified above. Further details on the encryption algorithms are given
in [6, 12, 13]. in [6, 12, 13].
3.3.3 Hybrid Encryption 3.3.3 Hybrid Encryption
If a combination of asymmetric and symmetric encryption has been used 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 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 following structure. This effectively takes the form of a Privacy header
followed by the encrypted SDP payload, the precise format depending on followed by the encrypted SDP payload, the precise format depending on
whether PGP or PKCS#7 formats have been used. The specific details for 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 each of these formats are described in Sections 3.3.3.1 and 3.3.3.2
respectively. respectively and, as with authentication, implementations MUST support
PGP with PKCS#7 being OPTIONAL.
Kirstein et al. [PAGE 12]
Privacy Header: Privacy Header:
1 2 3 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 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 | | | V=1 |P| Type | Header Length | |
|+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+ | |+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+ |
| Format Specific Privacy Subheader | | Format Specific Privacy Subheader |
| .................. | | .................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes Notes:
Version, V: In this version the Version of the privacy Header is 1 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 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 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 last byte of the Privacy Header contains the number of padding bytes
(including the last byte) that must be discarded. (including the last byte) that must be discarded.
Format Type, Type: This can be either 1 for PGP or 2 for PKCS#7 format. 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. Header Length: This gives the length of the Privacy Header.
3.3.3.1 PGP Format Privacy Header 3.3.3.1 PGP Format Privacy Header
For the case when the Format Type is 1 the Format Specific Privacy 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 Subheader is composed of a PGP Public Key encrypted packet and the text
payload is a PGP Conventional Key Encrypted Packet. These are detailed 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 in [2]. The Public Key Cryptosystem is 1, this being defined as the RSA
system, and the only supported symmetric encryption algorithm is the system, and the only supported symmetric encryption algorithm is the
Kirstein et al. [PAGE 14]
IDEA algorithm, corresponding to the Conventional encryption type byte IDEA algorithm, corresponding to the Conventional encryption type byte
value of 1. value of 1.
3.3.3.2 PKCS#7 Format Privacy Header 3.3.3.2 PKCS#7 Format Privacy Header
If the Type is 2 then the Format Specific Privacy Header is composed of If the Type is 2 then the Format Specific Privacy Header is composed of
a PKCS#7 ContentInfo type with the ContentType being envelopedData. a PKCS#7 ContentInfo type with the ContentType being envelopedData.
These are detailed in [2]. In this case the Text Payload, which has been These are detailed in [2]. In this case the Text Payload, which has been
symmetrically encrypted with the algorithm specified in the symmetrically encrypted with the algorithm specified in the
contentEncryptionAlgorithm field, is effectively the encryptedContent contentEncryptionAlgorithm field, is effectively the encryptedContent
skipping to change at line 692 skipping to change at line 749
"Data". "Data".
3.3.4 Supported Algorithms 3.3.4 Supported Algorithms
It is the policy of the IESG that unencumbered algorithms should be used It is the policy of the IESG that unencumbered algorithms should be used
wherever possible. The only encumbered algorithm mandatory in the section wherever possible. The only encumbered algorithm mandatory in the section
below is RSA; we understand that arrangements are being made to avoid below is RSA; we understand that arrangements are being made to avoid
licence fees on this algorithm. At present implementations of suitable licence fees on this algorithm. At present implementations of suitable
unencumbered algorithms are not readily available. unencumbered algorithms are not readily available.
Kirstein et al. [PAGE 13]
3.3.4.1 Symmetric Encryption 3.3.4.1 Symmetric Encryption
If symmetric encryption alone is used then DES [6] and Triple-DES If symmetric encryption alone is used then DES [6] MUST be supported.
(DES EDE3 CBC) [17] MUST be supported.
3.3.4.2 Hybrid Encryption 3.3.4.2 Hybrid Encryption
3.3.4.2.1 PGP Format 3.3.4.2.1 PGP Format
- Content Encryption - the IDEA symmetric encryption algorithm with - Content Encryption - the IDEA symmetric encryption algorithm with
a key length of 128 bits MUST be supported. a key length of 128 bits MUST be supported.
- Digest Algorithm - the MD5 [18] Message Digest Algorithm MUST be - Digest Algorithm - the MD5 [18] Message Digest Algorithm MUST be
supported. supported.
- Digest Encryption Algorithm - the asymmetric rsaEncryption algorithm - Digest Encryption Algorithm - the asymmetric rsaEncryption algorithm
[10] MUST be supported with key sizes from 512 bits to 1024 bits. [10] MUST be supported with key sizes from 512 bits to 1024 bits.
- Key encryption Algorithm - the asymmetric rsaEncryption algorithm - Key encryption Algorithm - the asymmetric rsaEncryption algorithm
[10] MUST be supported with key sizes from 512 bits to 1024 bits. [10] MUST be supported with key sizes from 512 bits to 1024 bits.
3.3.4.2.2 PKCS#7 Format 3.3.4.2.2 PKCS#7 Format
- Content Encryption - Receiving agents SHOULD support decryption using In order to maintain wide interoperability the algorithms supported
the RC2 algorithm [20] at a key size of 40 bits (RC2/40). here follow [23] where fuller details can be found.
Receiving agents MUST support decryption using Triple-DES [17].
Sending agents SHOULD support encryption with RC2/40 and
Triple-DES.
- Digest Algorithm - Receiving agents MUST support SHA-1 [19] and MD5 - KeyEncryptionAlgorithmIdentifier
[18]. Sending agents should use SHA-1.
- Digest Encryption Algorithm - Receiving agents and sending agents Sending and receiving agents MUST support Diffie-Hellman defined
MUST support rsaEncryption [10]. Receiving agents MUST support in [21].
verification of signatures using RSA public key sizes from 512
bits to 1024 bits.
- Key encryption Algorithm - Receiving agents MUST support Kirstein et al. [PAGE 15]
rsaEncryption [10]. Sending agents MUST support rsaEncryption and Receiving agents SHOULD support rsaEncryption [10]. Incoming
encryption of symmetric keys with RSA public keys at key sizes encrypted messages contain symmetric keys which are to be
from 512 bits to 1024 bits. decrypted with a user's private key. The size of the private key
is determined during key generation.
Kirstein et al. [PAGE 14] Sending agents SHOULD support rsaEncryption. Sending agents
Appendix A: Authors' Addresses 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.
Peter Kirstein, Goli Montasser Kohsari and Edmund Whelan are at - SignatureAlgorithmIdentifier
University College London and their contact details are:
P.Kirstein@cs.ucl.ac.uk Tel: +44 171 380 7286 Sending and receiving agents MUST support id-dsa defined in
G.Montasser-Kohsari@cs.ucl.ac.uk Tel: +44 171 380 7215 [22]. The algorithm parameters MUST be absent (not encoded as
E.Whelan@cs.ucl.ac.uk Tel: +44 171 419 3688 NULL).
Dept of Computer Science Fax: +44 171 387 1397 Receiving agents SHOULD support rsaEncryption, defined in [10].
University College London Receiving agents SHOULD support verification of signatures using
Gower Street RSA public key sizes from 512 bits to 1024 bits.
London WC1E 6BT England
Acknowledgements Sending agents SHOULD support rsaEncryption. Outgoing messages
are signed with a user's private key.
SAP and SDP were originally based on the protocol used by the sd session - ContentEncryptionAlgorithmIdentifier
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 15] 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]
References References
[1] M.Handley `SAP: Session Announcement Protocol'' INTERNET-DRAFT, [1] M.Handley `SAP: Session Announcement Protocol'' INTERNET-DRAFT,
draft-ietf-mmusic-sap-00.txt, 11/27/1996. draft-ietf-mmusic-sap-00.txt, 11/27/1996.
[2] D.Atkins, '' PGP Message Exchange Formats'' , [2] D.Atkins, '' PGP Message Exchange Formats'' ,
RFC 1991, August 1996. RFC 1991, August 1996.
[3] PKCS#7, Cryptographic Message Syntax Standard, RSA Laboratories, [3] PKCS#7, Cryptographic Message Syntax Standard, RSA Laboratories,
Version 1.5, November 1993 Version 1.5, November 1993
skipping to change at line 812 skipping to change at line 878
[14] For details of ENTRUST see http://www.entrust.com/ [14] For details of ENTRUST see http://www.entrust.com/
[15] For details of SECUDE see http://www.darmstadt.gmd.de/secude/ [15] For details of SECUDE see http://www.darmstadt.gmd.de/secude/
[16] PKCS#9 Selected Attribute Types, [16] PKCS#9 Selected Attribute Types,
RSA Laboratories, Version 1.1, November 1993 RSA Laboratories, Version 1.1, November 1993
[17] W. Tuchman, "Hellman Presents No Shortcut Solutions to DES" [17] W. Tuchman, "Hellman Presents No Shortcut Solutions to DES"
IEEE Spectrum, v. 16, n. 7, July 1979, pp 40-41 IEEE Spectrum, v. 16, n. 7, July 1979, pp 40-41
Kirstein et al. [PAGE 16]
[18] "The MD5 Message Digest Algorithm" RFC 1321 [18] "The MD5 Message Digest Algorithm" RFC 1321
Kirstein et al. [PAGE 17]
[19] NIST FIPS PUB 180-1 "Secure Hash Standard" [19] NIST FIPS PUB 180-1 "Secure Hash Standard"
National Institute of Standards and Technology, National Institute of Standards and Technology,
U.S. Department of Commerce, DRAFT, 31 U.S. Department of Commerce, DRAFT, 31
[20] "Description of the RC2 Encryption Algorithm", [20] "Description of the RC2 Encryption Algorithm",
Internet Draft draft-rivest-rc2desc. Internet Draft draft-rivest-rc2desc.
Kirstein et al. [PAGE 17] [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"
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]
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/