draft-ietf-mmusic-sap-sec-00.txt   draft-ietf-mmusic-sap-sec-01.txt 
Internet Draft Peter Kirstein Internet Engineering Task Force MMUSIC WG
IETF MMUSIC WG Goli Montasser-Kohsari Internet Draft P. Kirstein
March 26, 1997 Edmund Whelan draft-ietf-mmusic-sap-sec-01.txt G. Montasser-Kohsari
<draft-ietf-mmusic-sap-sec-00.txt> July 29th 1997 E. Whelan
Expires September 26, 1997 Expires: January 29th 1998 University College London
Specification of Security in SAP Using Public Key Algorithms Specification of Security in SAP 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
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ``work in progress.'' or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
Distribution of this document is unlimited. Distribution of this document is unlimited.
Abstract ABSTRACT
The Session Announcement Protocol (SAP) is specified in such a way that The Session Announcement Protocol (SAP) has been specified in such a way
authentication and privacy can be assured. However but the algorithms that authentication and privacy can be assured. However the algorithms
and mechanisms to achieve such security are not prescribed in the and mechanisms to achieve such security are not prescribed in the
current draft. This document extends the SAP protocol, by describing current draft. This document extends the SAP protocol, by describing
specific algorithms and formats of authentication and encryption specific algorithms and formats of authentication and encryption formats
formats based on the PGP and PKCS#7 standards. It is a companion based on the DES, PGP and PKCS#7 standards. It is a companion document
document to draft-ietf-mmusic-sap. to draft-ietf-mmusic-sap.
This document is a product of the Multiparty Multimedia Session Control This document is a product of the Multiparty Multimedia Session Control
(MMUSIC) working group of the Internet Engineering Task Force Comments (MMUSIC) working group of the Internet Engineering Task Force Comments
are solicited and should be addressed to the working group's mailing are solicited and should be addressed to the working group's mailing
list at confctrl@isi.edu and/or the authors. list at confctrl@isi.edu and/or the authors.
Kirstein et al. Document Expiration 26 September 1997 [PAGE 1] Kirstein et al. [PAGE 1]
GLOSSARY
Glossary
ASN Abstract Syntax Notation ASN Abstract Syntax Notation
CT Content Type CT Content Type
CTB Cipher Type Byte CTB Cipher Type Byte
DA Digest Algorithm DA Digest Algorithm
DEA Digest Encryption Algorithm DEA Digest Encryption Algorithm
DES Data Encryption Standards DES Data Encryption Standards
EAID Encryption Algorithm Identifier EAID Encryption Algorithm Identifier
EK Encryption Key
EKID Encryption Key Identifier EKID Encryption Key Identifier
ID Identifier
IETF Internet Engineering Task Force IETF Internet Engineering Task Force
MD Message Digest MD Message Digest
MMUSIC Multiparty Multimedia Session Control MMUSIC Multiparty Multimedia Session Control
PEM Privacy Enhanced Mail PEM Privacy Enhanced Mail
PGK Public Group Key
PGKID Public Group Key Identifier
PGP Pretty Good Privacy PGP Pretty Good Privacy
PH Privacy Header PH Privacy Header
PK Public Key
PKCS Public Key Cryptographic System PKCS Public Key Cryptographic System
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
SGK Secret Group Key SK Secret Key
SHA Secure Hash Algorithm SGK Group Key
SHA Hash Algorithm
Kirstein et al. Document Expiration 26 September 1997 [PAGE 2] Kirstein et al. [PAGE 2]
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 can 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 [1] allows (SAP) described in a companion draft [1]. The SAP protocol allows for
for the incorporation of authentication of the announcement originator, the incorporation of authentication of the announcement originator, and
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. SAP Session Description, are detailed in the draft.
This document describes the format of the authentication header for This document describes the format of the authentication header for SAP
SAP data packets that use security services based on PGP [2] orPKCS#7 data packets that use security services based on PGP [2] or PKCS#7 [3].
[3]. The format based loosely on PKCS#7 is referred to as Simple The SAP document also provides for the confidentiality services required
Public Key Format. Appendix C contains further details of PKCS#7 for the SDP payload [4], which describes the conference set-up
format security and possible future implementation plans. The SAP parameters. This document describes how both symmetric and hybrid
document also provides the confidentiality services required for the symmetric/public key encryption algorithms should be used to provide
SAP payload [4], which describes the conference set-up parameters. This private announcements.
document describes how hybrid symmetric and public key encryption
algorithms should be used to provide private announcements.
Much of this document is concerned with security considerations; these Much of this document is concerned with security considerations which
security considerations have not yet been subject to suitable have not yet been subject to suitable peer-review, and this document
peer-review, and this document should not be considered authoritative should not be considered authoritative in this area.
in this area.
2. Authentication and Encryption of Session Announcement 2. Authentication and Encryption of Announcements
2.1 Introduction 2.1 Introduction
It is necessary to provide authentication and integrity of the Session It is necessary to provide authentication and integrity of the Session
Announcement to ensure that only authorised persons modify Session Announcement to ensure that only authorised persons modify Session
Announcements and to provide facilities for announcing securely Announcements and to provide facilities for announcing securely
encrypted sessions - providing the relevant proposed conferees with the encrypted sessions - providing the relevant proposed conferees with the
means to decrypt the data streams. The Session Announcements are made means to decrypt the data streams. The Session Announcements are made to
to announce to all potential conferees the existence of a conference. announce to all potential conferees the existence of a conference. It
It has, however, another function - to try to minimise conflicts for has, however, another function - to try to minimise conflicts for Mbone
Mbone resources by spreading out the number of simultaneous resources by spreading out the number of simultaneous conferences. Thus
conferences. Thus there are a number of threats which we must try to there are a number of threats which we must try to address in the
address in the securing of the Session Announcement, and some securing of the Session Announcement, and some constraints. These
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 Here it is necessary to ensure that the Session Announcement comes from
from the person claimed, and is indeed an authorised announcement. the person claimed, and is indeed an authorised announcement. Since
Since subsequent announcements will modify caches of future subsequent announcements will modify caches of future conferences, it is
conferences, it is possible otherwise to spoof an original possible otherwise to spoof an original announcement, and thereby at
announcement, and thereby at least cause a Denial of Service attack; least cause a Denial of Service attack
Kirstein et al. Document Expiration 26 September 1997 [PAGE 3]
- 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 tools Here it is at least necessary to hide the details of the addresses and
used. Because of the desire 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 desirable to keep at least the time of a conference known, even if all
all other details are concealed. other details are concealed.
Three types of announcement will be supported: unsecured, Kirstein et al. [PAGE 3]
authenticated, authenticated and encrypted. The authenticated and the
authenticated and encrypted types are described below. The exact
formats depend on whether the PGP [2] or Simple Public Key mechanisms
are used, but this detail is elaborated in Section 3.2 and 3.3.
2.2 Authenticated Announcements 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.
A message digest of the announcement is calculated by the announcement 2.2 Symmetric and Asymmetric Encryption
originator. The originators secret key is used to encrypt the message
digest and an electronic timestamp, thus forming a digital signature, The simplest versions of encryption used are symmetric ones; here the
or signature certificate. The originator sends the digital signature same encryption key 'a' is used to encrypt and decrypt a message. This
along with the message; the receiver receives the message and the means that, if E{a,M) is the operation of encrypting the message M with
digital signature, and recovers the original message digest from the the key a and algorithm E, then the operation E{a, E{a, M}} reproduces
digital signature by decrypting it with the sender's public key. The the original message M. Because this form of encryption relies on the
receiver computes a new message digest from the message, and checks to sender and receiver having the same key, it cannot be used for
see if it matches the one recovered from the digital signature. If it authentication. An alternative form of encryption is asymmetric
matches, then that proves the message was not altered, and that it came encryption. Here two keys, a and b, are used. When these are used one
from the originator who owns the public key used to check the 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
System (PKCS) can be derived in which one of the keys, say the Public
Key (PK), is published in some way while the other, the Secret Key (SK),
is kept secret. Using such a PKCS, it is possible to achieve both
confidentiality and authentication. Encrypting a message with the
recipient's Public Key ensures confidentiality as only the recipient
with the corresponding SK can decrypt the message. Encrypting a message
with the SK of the sender ensures authentication as only the sender
could have sent the message initially whereas anybody having access to
the Public Key can verify that it was indeed sent by the person holding
the corresponding Secret Key.
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.
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
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
Kirstein et al. [PAGE 4]
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. signature.
The digital signature service involves the use of a hash code, or Each Session announcement contains a message ID hash [4]. The
message digest, algorithm, a public-key encryption algorithm, and the specifications for SAP announcements [1] states that such announcements
private component of a public key pair and a timestamp. The sequence is may be repeated frequently, but that if any change is made in the
as follows: 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.
- the originator creates a payload To save space in the announcement message, only a public key identifier
- the originator generates a hash of the payload and timestamp is generally included. It is then assumed that the public key itself
- the originator encrypts the hash code using his own or the has either been distributed previously or can be retrieved from a cache
conference groups private key or directory. Optionally the Public Key itself can be included in the
- the encrypted hash code and the public key are pre-pended to the announcement removing the need for prior distribution. Consequently,
payload the receiver decrypts the hash code using the public key providing that the Public Key is already available in a local cache or
received. Directory, or is distributed with the announcement, one can be sure that
- the receiver generates a new hash code for the received payload the same originator sent the announcement. Only if the full public key
and timestamp and compares it to the decrypted hash code. If the information, and a Certificate Authority infrastructure, are accessible
two match, the payload is accepted as authentic. [5], can the originator be identified.
To save space in the announcement message, optionally only a public key 2.4 Authenticated and Encrypted Announcements
identifier need be included; it is then assumed that the public key
identifier, and the public key, have been distributed previously, or
can be retrieved from a cache or directory. Provided the Public Key
already exists in such a form, 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 [5], can the originator be identified.
Kirstein et al. Document Expiration 26 September 1997 [PAGE 4] 2.4.1 Introduction
2.3 Encrypted Announcements 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.3.1 Use of Symmetric Encryption 2.4.2 Distribution of Session Encryption Keys
Algorithms Announcements may be encrypted using a symmetric encryption There are various ways that the SEK could be distributed; all rely on
stage to provide security. If this mechanism is used, a random Session distributing some shared secret in advance to the intended participants
Encryption Key (SEK) must be generated and conveyed in advance to the in the conference group. When this process takes place out of band, it
intended participants of a conference group. This process takes place is not described further in this document.
out-of-band and is not described in this draft. Session announcements Many symmetric encryption algorithms, e.g. DES [6] are known to be easy
may then be made to the appropriate session announcement address, to break; with such algorithms, it is undesirable to re-use the SEK many
encrypted so that they can be decrypted only by recipients previously times. For this reason, and to improve security, a set of SEKs may be
authorised by being provided with the SEK. Many symmetric encryption distributed out-of-band; the recipients may then try to decrypt the
algorithms, e.g. DES [6], are known to be easy to break. For this announcement by trying each of these SEKs in turn.
reason, and to improve security, a set of SEKs may be distributed
out-of-band, and the recipients may then try to decrypt the
announcement by trying each of the set of SEKs. To improve the
efficiency of this process, an Encryption Key Identifier (EKID), and an
Encryption Algorithm Identifier (EAID) are normally distributed with
the SEK. This (EKID, EAID, SEK) triplet uniquely identifies the
mechanism and parameters required to decrypt the Session Announcement.
Use of Key Identifiers is undesirable if different sessions are to be
announced using the same DES key.
2.3.2 Use of Hybrid Encryption Public Key Algorithms Together With As in Section 2.3, one may use the fact that if any change is made in
Symmetric Ones 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
The (EKID, EAID, SEK) triplet must be received, and possibly cached by Kirstein et al. [PAGE 5]
all the authorised parties prior to the reception of the SAP
announcement. The process of ensuring the receipt, managing the cache,
and trying several keys can be relatively complex and expensive; for
this reason the number of such triplet that must be distributed should
be minimised. One mechanism for minimising the number of triplet
required is to use Public Key Cryptography as in the Authenticated
Announcements of Section 2.2. It would be possible to use these
encryption algorithms on the whole announcement message; this would,
however, 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.3.1. A Privacy Header (PH) is constructed containing the SEK, which
is encrypted with the asymmetric encryption algorithm. It is now
necessary to distribute a quadruplet of {Encryption Key Identifier
(EKID), Encryption Algorithm Identifier (EAID), Secret Group Key (SGK)
and Public Group Key (PGK)} i.e. {EKID,EAID,SGK,PGK} to identify
uniquely the mechanism and parameters required to decrypt the SEK.
However, this quadruplet 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.
Kirstein et al. Document Expiration 26 September 1997 [PAGE 5] 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 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 not possible to use the same Header to authenticate the sender uniquely,
uniquely; though it is authenticated automatically that the sender is though it is authenticated automatically that the sender is one of the
one of the group which has reserved the asymmetric encryption key group which has reserved the asymmetric encryption key pair. It is
pair. By using a different Authentication Key for the authentication still possible to authenticate the identity of the sender by using a
of Section 2.2 from the Encryption Keys of this section, it is possible different Authentication Key for the Authentication Header as described
to still authenticate the identity of the sender. in Section 2.3.
2.3.3 Encrypting Announcements 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.
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 .
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 symmetric encryption. In this case each such encryption key is used only
only once; a new Session Encryption Key (SEK) is generated as a random once; a new Session Encryption Key (SEK) is generated as a random number
number for each announcement. Since it is to be used only once, the SEK for each announcement. Since it is to be used only once, the SEK is
is bound to the message and transmitted with it in a Privacy Header. bound to the message and transmitted with it in a Privacy Header. The
The sequence is as follows: The Privacy Header contains the SEK, sequence is as follows: The Privacy Header contains the SEK, encrypted
encrypted with the groups Public Group Key, together with the groups with the group's Public Group Key, together with information identifying
Public Key Identifier (PGKID). This is followed by the encrypted
Payload.
2.3.4 Decrypting Announcements Kirstein et al. [PAGE 6]
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 Upon receiving a new announcement with the encryption bit set, a
receiver should attempt to decrypt the announcement with its group receiver should attempt to decrypt the announcement with the relevant
private key or its own private key - as indicated by the PGKID. group private key or their own private key as indicated in the Privacy
Header. The sequence is as follows:
The sequence is as follows: 1. Prior to the announcement, the group's Public/Secret Group Key
pair is distributed securely.
- The receiving participants derive the Secret Group Key (SGK) and the 2. From the announcement, the receiving participants determine
group key algorithm from the Public Group Key Identifier and its which Public Group Key has been used by looking at the
related information which has been distributed previously. information contained in the Privacy Header.
- They then decrypt the Session Encryption Key (SEK) with the SGK and 3. They then decrypt the Session Encryption Key (SEK) with the SGK
obtain the Encryption Algorithm Identifier (EAID) from the Privacy corresponding to the PGK identified in Step 2 and obtain other
Header. necessary information such as the content encryption algorithm
from the Privacy Header.
- The authorised receivers extract the text payload by using the SEK 4. The authorised receivers decrypt the encrypted text payload using
and the relevant symmetric decryption algorithm to decrypt the the SEK and the relevant symmetric content encryption algorithm,
encrypted text payload. which was used to encrypt the payload.
Note that if an encrypted announcement is being announced via a proxy, 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 then there may be no way for the proxy to discover that the announcement
announcement has been superseded, and so it may continue to relay the has been superseded, and so it may continue to relay the old
old announcement in addition to the new announcement. SAP provides no announcement in addition to the new announcement. SAP provides no
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. Document Expiration 26 September 1997 [PAGE 6]
2.3.5 Encryption Algorithm Identifier (EAID)
This is an 8-bit integer which is mentioned in Sections 2.3.1 and
2.3.2. It is distributed with the Key ID in the form of: {Encryption
Key ID, Encryption Algorithm ID, Encryption Key(s)}
It is used for three purposes: to determine whether symmetric or
asymmetric encryption is used, to specifiy the encryption algorithm,
and to specify the encryption key length. For this reason, its format
is given below:
BIT 0 1 2 3 4 5 6 7
TYPE ALGORITHM LENGTH
TYPE (1 bit) can take the values 0 or 1; the former is symmetric, the
latter Public Key
ALGORITHM (3 bits) denotes the encryption Algorithm, further details
are given in Section 3.3.6.
LENGTH (4 bits) denotes the key length; further details are given in
Section 3.3.6
3. Secured SAP Packet Formats 3. Secured SAP Packet Formats
Both Authentication and Confidentiality can be achieved using PGP [2] Both Authentication and Privacy can be achieved using PGP [2] or PKCS#7
or Simple Public Key format packets. These formats are explained in [3] format packets. In Section 3.1 we discuss the generic packet format
greater detail below. In Section 3.1 we discuss the generic packet defined in SAP [1]. In Section 3.2 we consider the formats of the
format defined in [1]; this is still only at the draft stage, so any Authentication Header, and in Section 3.3 that of the encrypted payload.
changes in it will have to be tracked in future versions of this
document. In Section 3.2 we consider the formats of the Authentication
Header, and in Section 3.3 that of the Text Payload.
It would be possible to define our own versions of the packets It would be possible to define our own versions of the packets for this
completely for this application. In that case the formats would be application. In that case the formats would be simpler, but all the
simpler, but all the implementations would have to be coded using the implementations would have to be coded using the basic encryption
basic encryption libraries, and a new infrastructure would have to be libraries, and a new infrastructure would have to be defined. Both PGP
defined. Both PGP and PKCS#7 already have complete implementations; by and PKCS#7 already have complete implementations and, by using their
using their formats, several application tool kits are already formats, several application tool kits are already available (e.g.
available (e.g. ENTRUST [14], SECUDE [15]). In addition, these formats Entrust [14], Secude [15]). In addition, these formats also have
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.
Kirstein et al. Document Expiration 26 September 1997 [PAGE 7] Kirstein et al. [PAGE 7]
3.1 SAP Packet Format 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.
The SAP data packets as defined in [1] is of the following format: 3.1 Secured SAP Packet Format
The SAP data packets as defined in [1] has the following format:
1 2 3 1 2 3
BIT 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=2 | MT |E|C| Header Length | 16 bit Message ID Hash | | V=2 | MT |E|C| Header Length | 16 bit Message ID Hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating Source | | Originating Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Authentication Header (Optional) | | Authentication Header (Optional) |
| ... | | .................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encryption Key id (Optional) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32 bit Time-Out Field (Optional) | | 32 bit Time-Out Field (Optional) |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Text Payload (Possibly Encrypted) | | Text Payload (Possibly Encrypted) |
| .................. | | .................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes: Notes:
V: Version Number (3 bits). This is 2 for SAP [1] Version Number, V: This is a 3-bit field and has the value 2 for this
version of SAP [1]
MT: Message Type
The value being either:
0. Session description announcement packet. The text payload is Message Type, MT: This defines the contents of the payload and can be
an SDP session description, as described in [4].
1. Session description deletion packet. The text payload is a 0. Session Descriptor Announcement Packet in which case the
single SDP line consisting of the origin field of the announcement payload is an SDP session description as described in [4]
to be deleted
E: Encryption Bit -.If the encryption bit is set, the text payload of 1. Session Description Deletion Packet in which case the payload
the SAP is encrypted is a singleSDP line containing the origin field of the
announcement to be deleted
C: Compressed bit - This bit indicates that the payload was compressed Encryption Bit, E: -. If this is set, the text payload has been
using the gzip compression utility [7] encrypted
Header length Compression Bit, C: If this is set the payload has been compressed using
the gzip compression utility [7]
This is an 8 bit unsigned quantity giving the number of 32 bit Header length: This is an 8 bit unsigned quantity giving the number of
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
Kirstein et al. Document Expiration 26 September 1997 [PAGE 8]
Message Identifier Hash Kirstein et al. [PAGE 8]
A 16 bit quantity that, when used in combination with the Message Identifier Hash: This is a 16 bit quantity that, when used in
originating source, provides a globally unique id identifying combination with the originating source, provides a globally unique
the precise version of this announcement. The message id hash id identifying the precise version of this announcement. The message
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
the message should always be parsed. the message should always be parsed.
Originating Source 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
This 32 bit field gives the IP address of the original source of if the message has not passed through a proxy relay and if the message
the message. It is permissible for this to be zero if the id hash is also zero. This is intended for backward compatibility with
message has not passed through a proxy relay and if the message id SAPv0 clients only.
hash is also zero. This is intended for backwards compatibility
with SAPv0 clients only.
Authentication Header
The authentication Header can be used for two purposes: Authentication Header: This can be used for two purposes:
- Verification that changes to a session description or deletion 1. Verification that changes to a session description or deletion
of a session are permitted. of a session are permitted
- Authentication of the identity of the session creator. 2. Authentication of the identity of the session creator.
In some circumstances only verification is possible because a In some circumstances only verification is possible because a
certificate signed by a mutually trusted person or authority is not certificate signed by a mutually trusted person or authority is not
available. However, under such circumstances, the session available. However, under such circumstances, the session originator
originator can still be authenticated to be the same as the can still be authenticated to be the same as the session originator of
session originator of previous sessions claiming to be from the previous sessions claiming to be from the same person. This may or may
same person. This may or may not be sufficient, depending on the not be sufficient, depending on the purpose of the session and the
purpose of the session and the people involved. The format of the people involved. The precise format of the Authentication Header is
Authentication Header is discussed in Section 3.2 discussed in Section 3.2.
Encryption Key Identifier
This is a 32 bit network byte integer which can be used to identify
the triplet or quadruplet described Section 2.3.1 and 2.3.2 of
{Encryption Key Identifier, Encryption Algorithm Identifier,
Encryption Key(s)}. PGP uses a 64-bit Key Identifier in its
Software. [ It would be more consistent if we used 64-bit Key
Identifiers throughout. However, this would require a corresponding
change in the SAP document [1] ].
If the Encryption Algorithm Identifier Type is 0, then the
encryption is symmetric. A triplet is distributed out-of-band with
a singe symmetric key, and the methods of Section 2.3.1 are
applied.
If the Encryption Algorithm Identifier Type is 1, then the
encryption is hybrid. A quadruplet is distributed out-of-band with
a secret/public key pair, and the methods of Section 2.3.2 are
applied.
Kirstein et al. Document Expiration 26 September 1997 [PAGE 9]
Key IDs are generated when a new key or key pair is chosen. For
Symmetric Encryption Keys, the Key IDs should be randomly
distributed. For Asymmetric Encryption Keys, the Key ID is related
algorithmically to the Public Group Key; further details are given
in Sections 3.2.2 and 3.2.3.
Use of the Encryption Key Identifier is not recommended if
different sessions are to be announced with the same DES key.
Time-out
When the session payload is encrypted, and the session description Timeout: When the session payload is encrypted, and the session
is being relayed or announced via a proxy, the detailed timing description is being relayed or announced via a proxy, the detailed
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 includes an additional 32-bit timestamp field stating when the session
session should be timed out. The digital signature in the should be timed out. The digital signature in the authentication
authentication header encompasses the time-out so that a session header encompasses the time-out so that a session cannot be
cannot be maliciously deleted by modifying its time-out in an maliciously deleted by modifying its time-out in an announcing proxy.
announcing proxy. The value is an unsigned quantity giving the NTP The value is an unsigned quantity giving the NTP time [8] in seconds
time [8] in seconds at which time the session is timed out. It is at which time the session is timed out. It is in network byte order
in network byte order
Text Payload
When there is no encryption, the encryption bit is not set and Privacy Header: This is present when the text payload has been encrypted
this format is as defined in the SDP [4] draft. using hybrid encryption.
Encrypted Text Payload 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.
This is present when the text payload has been encrypted. The Kirstein et al. [PAGE 10]
format is discussed in Section 3.3.
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. We have The generic format of the Authentication Header is given below. The
defined it both using the PGP and the Simple Public Key mechanisms. 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 1 2 3
BIT 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| | | V=1 |P| Auth | Header Length | |
|+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+ |
| Format Specific Authentication Subheader | | Format Specific Authentication Subheader |
| .. | | .................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
V: Version number Notes:
The SAP Authentication Header version number is 1 for this
release.(3 bits)
Kirstein et al. Document Expiration 26 September 1997 [PAGE 10]
P: Padding Bit Version Number, V: For this release the version number is 1 (3 bits)
If necessary the data in the Authentication Header is padded to be Padding Bit, P: If necessary the data in the Authentication Header is
a multiple of 32 bits and the Padding bit is set. In this case the padded to be a multiple of 32 bits and the Padding bit is set. In this
last byte of the Authentication Header contains the number of case the last byte of the Authentication Header contains the number of
padding bytes (including the last byte) that must be discarded. padding bytes (including the last byte) that must be discarded.
Auth Authentication Type, Auth: The Authentication Type is a 4 bit encoded
field that denotes the authentication infrastructure the sender
The Authentication Type is a 4 bit encoded field that denotes the expects the recipients to use to check the authenticity and integrity
authentication infrastructure the sender expects the recipients to of the information. This defines the format of the Authentication
use to check the authenticity and integrity of the information. Subheader and can take the values:
This defines the format of the Authentication Subheader and can
take the values:
1 PGP including the public key identifier
2 Simple Public Key Format including the public key
identifier
3 PGP with the public key included
4 Simple Public Key Format with the public key included
5 PGP with the certificate included
6 Simple Public Key Format with the certificate included
The specific formats for the PGP and Simple Public Key variants of the 1. PGP Format
Header are discussed in Sections 3.2.2 and 3.2.3. 2. PKCS#7 Format
3. PGP Format with the 'Certificate' included
4. PKCS#7 with the Certificate included
3.2.2 PGP Format 3.2.2 PGP 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 Authentication Subheader comprises a digital signature packet the basic Format Specific Authentication Subheader comprises a digital
as below. This involves the use of a hash code, or message digest signature packet as described in [2]. This involves the use of a hash
algorithm, and a public key encryption algorithm. The format for code, or message digest algorithm, and a public key encryption
applying PGP to the payload for authentication purposes is discussed algorithm. For the case when the Authentication type is 1 the Subheader
below. For case 1 the Authentication Subheader contains a Digital contains a Digital Signature Packet only with the hexadecimal signature
Signature Packet only. For cases 3 and 5 a Public Key Packet or a classification being <00> or <01>. The only Message Digest Algorithm is
Certificate Packet are also contained respectively. These are defined 1 (MD5) and the Public Key Cryptosystem (PKC) is 1, this being the RSA
in Appendix B and [2]. 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
Digital Signature Packet: following individual packets:
a) packet structure field (2, 3, or 5 bytes); 10001000(1 byte plf)
10001001 (2 byte plf) 10001010(4 byte plf) plf packet length field
b) version number = 2 or 3 (1 byte); (3)
c) length of following material included in MD calculation (1
byte, always value 5); (5)
d) (d1) signature classification (1 byte); (hex value 00 document)
(d2) signature time stamp (4 bytes); (time of signing)
e) key ID for key used for signing (8 bytes);
Kirstein et al. Document Expiration 26 September 1997 [PAGE 11]
f) public-key-cryptosystem (PKC) type (1 byte); (1 RSA)
g) message digest algorithm type (1 byte); (1 MD5)
h) first two bytes of the MD output, used as a checksum (2 bytes);
i) a byte string of encrypted data holding the RSA-signed digest.
The length of field (a) depends on the size of the key used for
signing. If 512, 768 or 1024 then the length will be 2 ,3 or 5
respectively. The first byte is Cipher Type Byte (CTB) and its
value is 10001000 for key size 512, 10001001 for key size 768 and
10001010 for key size 1024. The remaining 1,2 or 4 bytes of the
packet structure field gives the length of the packet.
The length of RSA signed digest of (i) also depends on the size of
the key used. For keys 512, 768 or 1024 the size is 64, 96 or 128
bytes respectively
3.2.3 Simple Public Key Format
The generic description of the PKCS#7 packets is presented in [3]. For
the Simple Public Key format the basic Authentication Subheader is as
follows:
1 2 3
BIT 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DA | E A I D | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64 bit key identifier |
| .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 128 bit payload digest |
| .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted block |
| .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes
DA, the Digest Algorithm Identifier (5 bits), specifies the
algorithm used to digest the data. This can currently have the
following values:
1 - RSA's MD2 algorithm as defined in RFC 1319.
2 - RSA's MD5 algorithm as defined in RFC 1321
3 - The SHA Secure Hash Algorithm
Kirstein et al. Document Expiration 26 September 1997 [PAGE 12]
EAID, the Encryption Algorithm Identifier(1 byte), specifies the Kirstein et al. [PAGE 11]
algorithm used to encrypt the digest with the originator's secret (a) A Public Key Packet which defines the RSA public key
key. Strictly speaking this field is optional as it is already (b) A UserID packet
uniquely specified by the Key Identifier which points to a (c) A Signature Packet
quadruplet which has already been distributed out-of-band. It is
repeated here solely for compatibility reasons.
Key Identifier (EKID) is the 64 least significant bits of the The Public Key packet again has the Public Key Cryptosystem 1. In the
public key of the originator. In the PKCS#7 standard the key is case of Signature Packet (c) the signature classification now takes the
identified by specifying the "issuerAndSerialNumber" of the hexadecimal values <10> to <13>. These packets are all detailed in [2].
certificate containing the public key. This has two fields namely
the Distinguished Name of the Certificate Issuer and the serial
Number of the Certificate. The Distinguished Name can be
arbitrarily long, being a sequence of Relative Distinguished Names,
and the Serial Number is simply an integer. This was considered to
be too long and the 64-bit key identifier, as used in PGP, was
thought to provide the necessary information.
Payload Digest is the 128 bit output from digesting the payload 3.2.3 PKCS#7 Format
with the DA.
Time Stamp is in NTP Time Format as specified in RFC1119 [8]. 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].
Encrypted Block: The input to the digest encryption process starts There will only be one signerInfo and related fields corresponding to
at the beginning of the Authentication Subheader and continues the originator of the SAP announcement. Although it would be possible
until the end of the UTCTime field. If the Digest Encryption to transfer the relevant information is a single signerInfo type rather
Algorithm is rsaEncryption the block type is 01 as specified for than the complete ContentInfo it is considered preferable to use the
PEM message digest encryption in RFC1423. 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.
If the Authentication Type is 4 or 6 then either a public key or a In addition, for both type 2 and 4, use is made of the ability in PKCS#7
certificate is included after the basic Subheader. 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.
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 to encrypt the SDP text payload [4]. If no encryption has been used
used only the Text payload is present. If encryption has been used then only the Text payload is present.
the Encryption Key Identifier field points to either a triplet for
symmetric encryption or a quadruplet for asymmetric encryption. 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 that 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
Kirstein et al. [PAGE 12]
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 3.3.2 Symmetric Encryption
If the Encryption Algorithm Identifier indicates use of symmetric If symmetric encryption alone has been used then the encrypted payload
encryption, ie the first bit is zero, then the payload has been has a random field added prior to encryption as below.
encrypted symmetrically with no use of asymmetric encryption. In
addition the encrypted payload has a random field added prior to
encryption as below:
Kirstein et al. Document Expiration 26 September 1997 [PAGE 13]
1 2 3 1 2 3
BIT 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P| 31 bit random field | | P| 31 bit random field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| text payload | | Text Payload |
| ....... | | . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes Notes
Random Field Random Field: This field is only present when payload is encrypted
using symmetric encryption and is used to perform the randomisation
This field is only present when payload is encrypted using tasks normally performed by an initialisation vector in algorithms
symmetric encryption and is used to perform the randomisation task such as DES. This 31-bit field should contain a genuinely random
normally performed by an initialisation vector in algorithms such
as DES. This 31 bit field should contain a genuinely random
number. number.
P: Encryption Padding Bit Padding Bit, P: This bit indicates that the payload was padded prior to
encryption. The last byte of the encrypted payload indicates how many
This bit indicates that the payload was padded prior to encryption. padding bytes were added.
The last byte of the encrypted payload indicates how many padding
bytes were added.
The data following the Timeout 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 specified above. Further details on the encryption algorithms are given
given in [6, 12, 13]. in [6, 12, 13].
3.3.3 Hybrid Encryption 3.3.3 Hybrid Encryption
If the value of the first bit of the Encryption Algorithm Identifier is If a combination of asymmetric and symmetric encryption has been used
set to 1, then hybrid encryption is used; currently only those based on then the part of the SAP packet following the time-out field has the
PGP or Simple Public Key formats are defined for the asymmetric following structure. This effectively takes the form of a Privacy header
portions. In these cases a Privacy Header (PH) is placed in front of followed by the encrypted SDP payload, the precise format depending on
SDP stream, which contains a Session Encryption Key (SEK). 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
In the PGP case there is no need for the Symmetric Encryption Algorithm respectively.
to be specified as this is always IDEA. The formats for the PGP and
Simple Public Key type privacy headers are as below.
3.3.4 PGP Format Privacy Header
If the value of the Encryption Algorithm Identifier Algorithm is 1 then
the PGP format is used. In this case the Privacy Header is composed of
a Public Key Encrypted Packet. The purpose of this packet is to convey
the one-time session key used to encrypt the message to the recipient
Kirstein et al. Document Expiration 26 September 1997 [PAGE 14]
in a secure manner. This is done by encrypting the session key with
the group public key so that only a member of the group can recover the
session key. (Note that plf is the packet length field)
Public Key Encrypted Packet:
76543210
a) a packet structure field; (2,3,5 bytes)) 10000100
(1 byte plf) 10000101(2 byte plf) 10000110 (4 byte plf)
b) a byte, giving the version number, 2 or 3; (1byte) 3
c) a number ID field, giving the ID of a key; (8bytes)
d) a byte, giving a PKC number; (1byte) (1 RSA)
e) a byte string of encrypted data (DEK). (64, 96 or 128 bytes)
3.3.5 Simple Public Key Format Privacy Header
If the value of the Encryption Algorithm Identifier Algorithm is 2 then Privacy Header:
the Simple Public Key Format is used. In this case the Privacy Header
is as follows:
1 2 3 1 2 3
BIT 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NGTH | E A I D 1 | E A I D 2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Session Encryption Key | | V=1 |P| Type | Header Length | |
| ............ | |+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+ |
| Format Specific Privacy Subheader |
| .................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes Kirstein et al. [PAGE 13]
LENGTH, (1 byte) this specifies the length of the Privacy Header
EAID1, the (asymmetric) Encryption Algorithm Identifier (1 byte)
identifies the asymmetric algorithm used to encrypt the Session
Encryption Key (SEK). The values this can take are specified in
Section 3.3.6. Strictly speaking this is not necessary as it has
already been completely specified by the Key Identifier in the main
SAP header. It is duplicated here for compatibility reasons.
EAID2, the (symmetric)Encryption Algorithm Identifier (1 byte)
identifies the symmetric algorithm used to encrypt the content. The
values this can take are specified in Section 3.3.6.
Kirstein et al. Document Expiration 26 September 1997 [PAGE 15]
Encrypted Session Encryption Key: This field contains the encrypted Notes
SEK. When the Key Encryption Algorithm is rsaEncryption the block
type is specified to be 2.
3.3.6 Supported Algorithms Version, V: In this version the Version of the privacy Header is 1
For the authentication the following Message Digest Algorithms are Padding Bit, P: If necessary the data in the Privacy Header is padded to
defined. Simple Public Key Format packets can use any of the specified be a multiple of 32 bits and the Padding bit is set. In this case the
types but PGP always uses MD5. last byte of the Privacy Header contains the number of padding bytes
(including the last byte) that must be discarded.
Message Digest Type Algorithm Format Type, Type: This can be either 1 for PGP or 2 for PKCS#7 format.
1 MD5 3.3.3.1 PGP Format Privacy Header
2 MD2
3 SHA
For the Encryption Algorithm Identifier there are several Algorithms For the case when the Format Type is 1 the Format Specific Privacy
supported for both Symmetric and Asymmetric Encryption. For Symmetric Subheader is composed of a PGP Public Key encrypted packet and the text
Encryption the first bit is set to 0 and for Asymmetric Encryption it payload is a PGP Conventional Key Encrypted Packet. These are detailed
is set to 1. The next 3 bits specify the Algorithm and the final four in [2]. The Public Key Cryptosystem is 1, this being defined as the RSA
bits denote the key size used. The following Algorithm Identifiers are system, and the only supported symmetric encryption algorithm is the
currently defined: IDEA algorithm, corresponding to the Conventional encryption type byte
value of 1.
EAID Algorithm ALG Key Length 3.3.3.2 PKCS#7 Format Privacy Header
00010010 DES 1 56 bits
00100011 Tiple DES 2 112 bits
00110100 IDEA 3 128 bits
01000100 RC2 4 128 bits
01010100 RC4 5 128 bits
10010101 RSA/PGP 1 256 bits If the Type is 2 then the Format Specific Privacy Header is composed of
10010110 RSA/PGP 1 512 bits a PKCS#7 ContentInfo type with the ContentType being envelopedData.
10010111 RSA/PGP 1 768 bits These are detailed in [2]. In this case the Text Payload, which has been
10011000 RSA/PGP 1 1024 bits symmetrically encrypted with the algorithm specified in the
10011001 RSA/PGP 1 2048 bits contentEncryptionAlgorithm field, is effectively the encryptedContent
10100101 RSA/SPK 2 256 bits part of the structure. There will be only one recipientInfo structure
10100110 RSA/SPK 2 512 bits corresponding to the group certificate, which has been previously
10100111 RSA/SPK 2 768 bits distributed. The contentType in the EncryptedContentInfo structure is
10101000 RSA/SPK 2 1024 bits "Data".
10101001 RSA/SPK 2 2048 bits
The general format of the Encrypted Payload is given below. Here the 3.3.4 Supported Algorithms
format of the Privacy Header depends on whether PGP or Simple Public
Key (SPK) format is used. The Encrypted Text Payload is the result of
encrypting the SDP text payload with the Symmetric Encryption Key
specified in the Privacy Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In the case of the hybrid encryption the algorithms supported are
| Privacy Header | defined in [2,3] for PGP and PKCS#7 respectively. The details of the
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ algorithms used are an inherent part of the information sent in the
| Encrypted SDP Payload | Privacy Header and Authentication Header and so it is not necessary to
| .... .. | specify in advance which are supported; this is open to change as new
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ algorithms arise and older ones are shown to insecure.
Kirstein et al. Document Expiration 26 September 1997 [PAGE 16] For the purely symmetric encryption case then currently only DES is
supported with a 56-bit Key length.
Appendix A: Authors Addresses Kirstein et al. [PAGE 14]
Appendix A: Authors' Addresses
Peter Kirstein, Goli Montasser Kohsari and Edmund Whelan are at Peter Kirstein, Goli Montasser Kohsari and Edmund Whelan are at
University College London and their email-ids are: University College London and their contact details are:
P.Kirstein@cs.ucl.ac.uk P.Kirstein@cs.ucl.ac.uk Tel: +44 71 380 7286
G.Montasser-Kohsari@cs.ucl.ac.uk G.Montasser-Kohsari@cs.ucl.ac.uk Tel: +44 71 380 7215
E.Whelan@cs.ucl.ac.uk E.Whelan@cs.ucl.ac.uk Tel: +44 71 419 3688
Dept of Computer Science Dept of Computer Science Fax: +44 71 387 1397
University College London University College London
Gower Street Gower Street
London WC1E 6BT England London WC1E 6BT England
Kirstein et al. Document Expiration 26 September 1997 [PAGE 17]
Appendix B: PGP format
Public key Packet
a) Packet structure field (2 3 5 bytes) 100110 (As
defined in 1)
b) version number = 2 or 3 (1byte) (3)
c) time stamp of key creation (4bytes)
d) validity period in days (2 bytes) (0 means forever)
e) public key cryptosystem (PKC) type (1 byte) (1 RSA)
f) Multi-precision integer (MPI) of RSA public modulus n;
g) MPI of RSA public encryption exponent e
User ID Packet
a) packet structure field (2 bytes) 01110101
b) User Id String (users name and email id
enclosed in <>)
Certificate
a) one public key packet (defined above)
b) one or more user ID packets (defined above)
c) Zero or more signature packets (defined in Section 3.2.2)
Kirstein et al. Document Expiration 26 September 1997 [PAGE 18]
Appendix C: PKCS#7 format
It is expected that an Authentication Subheader which adheres to the
PKCS#7 standard will be implemented in a later version of the SAP
header protocol. This would enable compatibility between information
contained in the Authentication Subheader and S/MIME MUAs for example.
In this version of the standard it was considered that, although we
wanted to follow the PKCS standards fairly closely, we did not want to
force developers to implement full ASN.1 typing and BER encoding. The
header detailed in the main document follows PKCS#7 in principle as it
contains similar fields. One difference is the use of a Key Identifier
rather than "issuerAndSerialNumber" as detailed above. Also, Object
Identifiers were not used here.
In a PKCS#7 compliant SAP protocol it would be expected that the
Authentication Subheader would consist of an ASN.1 SignerInfo type as
below:
SignerInfo ::= SEQUENCE {
version Version,
IssuerAndSerialNumber IssuerAndSerialNumber,
digestAlgorithm DigestAlgorithmIdentifier,
authenticatedAttributes [0] IMPLICIT Attributes OPTIONAL,
digestEncryptionAlgorithm DigestEncryptionAlgorithmIdentifier,
encryptedDigest EncryptedDigest,
unauthenticatedAttributes [1] IMPLICIT Attributes OPTIONAL }
If the Authentication Type is "4" (PKCS#7 + public key) the public key
would be appended to the Authentication Subheader. This is in a form
equivalent to that defined in PKCS#1 as:
RSAPublicKey ::= SEQUENCE {
modulus INTEGER
publicExponent INTEGER }
If the Authentication Type is "6" (PKCS#7 + certificate) the
certificate would be appended to the Authentication Subheader. This
Certificate is an ASN.1 type as defined in X.509.
If asymmetric encryption is used a PKCS#7 compliant Privacy Header
would consist of an ASN.1 RecipientInfo and EncryptedContentInfo type
as below:
RecipientInfo ::= SEQUENCE {
version Version,
issuerAndSerialNumber IssuerAndSerialNumber,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
EncryptedContentInfo ::= SEQUENCE {
contentType ContentType,
contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
encryptedContent [0] IMPLICIT EncryptedContent OPT }
Kirstein et al. Document Expiration 26 September 1997 [PAGE 19]
Acknowledgements Acknowledgements
SAP and SDP were originally based on the protocol used by the sd SAP and SDP were originally based on the protocol used by the sd session
session directory from Van Jacobson at LBNL. The design of SAP was directory from Van Jacobson at LBNL. The European Commission under the
funded by the European Commission under the Esprit 7602 "MICE" project, Esprit 7602 "MICE" project, and the Telematics 1007 "MERCI" project
and the Telematics 1007 "MERCI" project. funded the design of SAP.
Kirstein et al. [PAGE 15]
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'' , RFC 1991, August [2] D.Atkins, '' PGP Message Exchange Formats'' ,
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
[4] M.Handley, V. Jacobson, ``SDP: Session Description Protocol'', [4] M.Handley, V. Jacobson, ``SDP: Session Description Protocol'',
INTERNET-DRAFT, draft-ietf-mmusic-sdp-02.txt, 11/27/1996. INTERNET-DRAFT, draft-ietf-mmusic-sdp-02.txt, 11/27/1996.
[5] R. Housley , W. Ford , T. Polk Internet public Key Infrastructure [5] R. Housley , W. Ford , T. Polk Internet Public Key Infrastructure
INETRNET- DRAFT, draft-ietf-pkix-ipki-part1-03.txt December 1996. INTERNET- DRAFT, draft-ietf-pkix-ipki-part1-03.txt December 1996.
[6] National Bureau of Standards, Data Encryption Standard, Federal [6] National Bureau of Standards, Data Encryption Standard, Federal
Information Processing Standards Publication 46, January 1977 Information Processing Standards Publication 46, January 1977
[7] P. Deutsch, ``GZIP file format specification version 4.3'', RFC [7] P. Deutsch, ``GZIP file format specification version 4.3'',
1952, May 1996. RFC 1952, May 1996.
[8] D. Mills, ``Network Time Protocol version 2 specification and [8] D. Mills, ``Network Time Protocol version 2 specification and
implementation", RFC1119, 1st Sept 1989. implementation", RFC1119, 1st Sept 1989.
[9]X.208 Specification of [9] X.208 Specification of Abstract Syntax Notation One (ASN.1)
Abstract Syntax Notation One (ASN.1) ITU-T Recommendations 1988 ITU-T Recommendations 1988
[10] PKCS #1 RSA Encryption Standard RSA Laboratories, Version 1.5, [10] PKCS #1 RSA Encryption Standard RSA Laboratories, Version 1.5,
November 1993 November 1993
[11] H. Schulzrinne, ``RTP Profile for Audio and Video Conferences with [11] H. Schulzrinne, ``RTP Profile for Audio and Video Conferences with
Minimal Control'', RFC 1890, January 1996 Minimal Control'', RFC 1890, January 1996
[12] P. Metzger, P. Karn, W. Simpson, The ESP Information Triple [12] P. Metzger, P. Karn, W. Simpson, The ESP Information Triple
DES-CBC Transformation, 10/02/1995 RFC850 DES-CBC Transformation, 10/02/1995 RFC850
[13] ANSI X3.92-1981. American National Standards Data Encryption [13] ANSI X3.92-1981. American National Standards Data Encryption
Algorithm. American National Standards Institute, Approved 30 Algorithm. American National Standards Institute,
December 19990 Approved 30 December 1990
[14] For details of ENTRUST see http://www.entrust.com/ [15] For [14] For details of ENTRUST see http://www.entrust.com/
details of SECUDE see http://www.darmstadt.gmd.de/secude/
Kirstein et al. Document Expiration: 26 September 1997 [PAGE 20] [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
Kirstein et al. [PAGE 16]
 End of changes. 

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