Internet Draft Peter Kirstein
IETF MMUSIC WG Goli Montasser-Kohsari
March 26, 1997 Edmund Whelan
<draft-ietf-mmusic-sap-sec-00.txt>
Expires September 26, 1997
Specification of Security in SAP Using Public Key Algorithms
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this document is unlimited.
Abstract
The Session Announcement Protocol (SAP) is specified in such a way that
authentication and privacy can be assured. However but the algorithms
and mechanisms to achieve such security are not prescribed in the
current draft. This document extends the SAP protocol, by describing
specific algorithms and formats of authentication and encryption
formats based on the PGP and PKCS#7 standards. It is a companion
document to draft-ietf-mmusic-sap.
This document is a product of the Multiparty Multimedia Session Control
(MMUSIC) working group of the Internet Engineering Task Force Comments
are solicited and should be addressed to the working group's mailing
list at confctrl@isi.edu and/or the authors.
Kirstein et al. Document Expiration 26 September 1997 [PAGE 1]
INTERNET-DRAFT March 26 1997
Glossary
ASN Abstract Syntax Notation
CT Content Type
CTB Cipher Type Byte
DA Digest Algorithm
DEA Digest Encryption Algorithm
DES Data Encryption Standards
EAID Encryption Algorithm Identifier
EKID Encryption Key Identifier
ID Identifier
IETF Internet Engineering Task Force
MD Message Digest
MMUSIC Multiparty Multimedia Session Control
PEM Privacy Enhanced Mail
PGK Public Group Key
PGKID Public Group Key Identifier
PGP Pretty Good Privacy
PH Privacy Header
PKCS Public Key Cryptographic System
SAP Session Announcement Protocol
SDP Session Descriptor Protocol
SEK Session Encryption Key
SGK Secret Group Key
SHA Secure Hash Algorithm
Kirstein et al. Document Expiration 26 September 1997 [PAGE 2]
INTERNET-DRAFT March 26 1997
1. Introduction
An Mbone session directory is used to advertise multimedia conferences,
and to communicate the session addresses (whether multicast or unicast)
and conference-tool- specific information necessary for participation.
Such sessions can be announced using the Session Announcement Protocol
(SAP) described in a companion draft [1]. The SAP protocol [1] allows
for the incorporation of authentication of the announcement originator,
and for privacy of the session details; however neither the choice of
authentication algorithms used, nor the mechanisms for encrypting the
SAP Session Description, are detailed in the draft.
This document describes the format of the authentication header for
SAP data packets that use security services based on PGP [2] orPKCS#7
[3]. The format based loosely on PKCS#7 is referred to as Simple
Public Key Format. Appendix C contains further details of PKCS#7
format security and possible future implementation plans. The SAP
document also provides the confidentiality services required for the
SAP payload [4], which describes the conference set-up parameters. This
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
security considerations have not yet been subject to suitable
peer-review, and this document should not be considered authoritative
in this area.
2. Authentication and Encryption of Session Announcement
2.1 Introduction
It is necessary to provide authentication and integrity of the Session
Announcement to ensure that only authorised persons modify Session
Announcements and to provide facilities for announcing securely
encrypted sessions - providing the relevant proposed conferees with the
means to decrypt the data streams. The Session Announcements are made
to announce to all potential conferees the existence of a conference.
It has, however, another function - to try to minimise conflicts for
Mbone resources by spreading out the number of simultaneous
conferences. Thus there are a number of threats which we must try to
address in the securing of the Session Announcement, and some
constraints. These include the following:
- Authentication and Integrity of Session Announcement
Here it is necessary to ensure that the Session Announcement comes
from the person claimed, and is indeed an authorised announcement.
Since subsequent announcements will modify caches of future
conferences, it is possible otherwise to spoof an original
announcement, and thereby at least cause a Denial of Service attack;
Kirstein et al. Document Expiration 26 September 1997 [PAGE 3]
INTERNET-DRAFT March 26 1997
- Confidentiality of Conference Details for Session Announcement
Here it is at least necessary to hide the details of the tools
used. Because of the desire to minimise schedule conflicts, it is
desirable to keep at least the time of a conference known, even if
all other details are concealed.
Three types of announcement will be supported: unsecured,
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
A message digest of the announcement is calculated by the announcement
originator. The originators secret key is used to encrypt the message
digest and an electronic timestamp, thus forming a digital signature,
or signature certificate. 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 that proves the message was not altered, and that it came
from the originator who owns the public key used to check the
signature.
The digital signature service involves the use of a hash code, or
message digest, algorithm, a public-key encryption algorithm, and the
private component of a public key pair and a timestamp. The sequence is
as follows:
- the originator creates a payload
- the originator generates a hash of the payload and timestamp
- the originator encrypts the hash code using his own or the
conference groups private key
- the encrypted hash code and the public key are pre-pended to the
payload the receiver decrypts the hash code using the public key
received.
- the receiver generates a new hash code for the received payload
and timestamp and compares it to the decrypted hash code. If the
two match, the payload is accepted as authentic.
To save space in the announcement message, optionally only a public key
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]
INTERNET-DRAFT March 26 1997
2.3 Encrypted Announcements
2.3.1 Use of Symmetric Encryption
Algorithms Announcements may be encrypted using a symmetric encryption
stage to provide security. If this mechanism is used, a random Session
Encryption Key (SEK) must be generated and conveyed in advance to the
intended participants of a conference group. This process takes place
out-of-band and is not described in this draft. Session announcements
may then be made to the appropriate session announcement address,
encrypted so that they can be decrypted only by recipients previously
authorised by being provided with the SEK. Many symmetric encryption
algorithms, e.g. DES [6], are known to be easy to break. For this
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
Symmetric Ones
The (EKID, EAID, SEK) triplet must be received, and possibly cached by
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]
INTERNET-DRAFT March 26 1997
It should be noted that because a Group Key is used in the above, it is
not possible to use the same Header to authenticate the sender
uniquely; though it is authenticated automatically that the sender is
one of the group which has reserved the asymmetric encryption key
pair. By using a different Authentication Key for the authentication
of Section 2.2 from the Encryption Keys of this section, it is possible
to still authenticate the identity of the sender.
2.3.3 Encrypting Announcements
We will now provide some more detail. If the payload is to be
compressed, this is performed prior to encryption .
When an announcement is to be encrypted, the payload is encrypted using
symmetric encryption. In this case each such encryption key is used
only once; a new Session Encryption Key (SEK) is generated as a random
number for each announcement. Since it is to be used only once, the SEK
is bound to the message and transmitted with it in a Privacy Header.
The sequence is as follows: The Privacy Header contains the SEK,
encrypted with the groups Public Group Key, together with the groups
Public Key Identifier (PGKID). This is followed by the encrypted
Payload.
2.3.4 Decrypting Announcements
Upon receiving a new announcement with the encryption bit set, a
receiver should attempt to decrypt the announcement with its group
private key or its own private key - as indicated by the PGKID.
The sequence is as follows:
- The receiving participants derive the Secret Group Key (SGK) and the
group key algorithm from the Public Group Key Identifier and its
related information which has been distributed previously.
- They then decrypt the Session Encryption Key (SEK) with the SGK and
obtain the Encryption Algorithm Identifier (EAID) from the Privacy
Header.
- The authorised receivers extract the text payload by using the SEK
and the relevant symmetric decryption algorithm to decrypt the
encrypted text payload.
Note that if an encrypted announcement is being announced via a proxy,
then there may be no way for the proxy to discover that the
announcement has been superseded, and so it may continue to relay the
old announcement in addition to the new announcement. SAP provides no
mechanism to chain modified encrypted announcements, so it is advisable
to announce the unmodified session as deleted for a short time after
the modification has occurred. This does not guarantee that all proxies
have deleted the session, and so receivers of encrypted sessions should
be prepared to discard old versions of session announcements that they
may receive (as identified by the SDP version field). In most cases
however, the only stateful proxy will be local to (and known to) the
sender, and an additional (local-area) protocol involving a handshake
for such session modifications can be used to avoid this problem.
Kirstein et al. Document Expiration 26 September 1997 [PAGE 6]
INTERNET-DRAFT March 26 1997
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
Both Authentication and Confidentiality can be achieved using PGP [2]
or Simple Public Key format packets. These formats are explained in
greater detail below. In Section 3.1 we discuss the generic packet
format defined in [1]; this is still only at the draft stage, so any
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
completely for this application. In that case the formats would be
simpler, but all the implementations would have to be coded using the
basic encryption libraries, and a new infrastructure would have to be
defined. Both PGP and PKCS#7 already have complete implementations; by
using their formats, several application tool kits are already
available (e.g. ENTRUST [14], SECUDE [15]). In addition, these formats
also have complete infrastructures defined around them. For these
reasons, we have chosen to retain enough compatibility to ease the
eventual implementation, while simplifying the formats as far as
possible within such a constraint. There is an additional advantage in
this approach; it will be possible to send session announcements by the
encrypted Session Invitation Protocol or by electronic mail using PGP
or S-MIME, and re-use much of the same code as with SAP.
Kirstein et al. Document Expiration 26 September 1997 [PAGE 7]
INTERNET-DRAFT March 26 1997
3.1 SAP Packet Format
The SAP data packets as defined in [1] is of the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=2 | MT |E|C| Header Length | 16 bit Message ID Hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Authentication Header (Optional) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encryption Key id (Optional) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32 bit Time-Out Field (Optional) |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Text Payload (Possibly Encrypted) |
| .................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes:
V: Version Number (3 bits). This is 2 for SAP [1]
MT: Message Type
The value being either:
0. Session description announcement packet. The text payload is
an SDP session description, as described in [4].
1. Session description deletion packet. The text payload is a
single SDP line consisting of the origin field of the announcement
to be deleted
E: Encryption Bit -.If the encryption bit is set, the text payload of
the SAP is encrypted
C: Compressed bit - This bit indicates that the payload was compressed
using the gzip compression utility [7]
Header length
This is an 8 bit unsigned quantity giving the number of 32 bit
words following the main SAP header that contains the
authentication data . If this is non-zero, the payload is
authenticated, and an Authentication Header is present.
Kirstein et al. Document Expiration 26 September 1997 [PAGE 8]
INTERNET-DRAFT March 26 1997
Message Identifier Hash
A 16 bit quantity that, when used in combination with the
originating source, provides a globally unique id identifying
the precise version of this announcement. The message id hash
should be changed if any field of the session description is
changed. A value of zero means that the hash should be ignored and
the message should always be parsed.
Originating Source
This 32 bit field gives the IP address of the original source of
the message. It is permissible for this to be zero if the
message has not passed through a proxy relay and if the message id
hash is also zero. This is intended for backwards compatibility
with SAPv0 clients only.
Authentication Header
The authentication Header can be used for two purposes:
- Verification that changes to a session description or deletion
of a session are permitted.
- Authentication of the identity of the session creator.
In some circumstances only verification is possible because a
certificate signed by a mutually trusted person or authority is not
available. However, under such circumstances, the session
originator can still be authenticated to be the same as the
session originator of previous sessions claiming to be from the
same person. This may or may not be sufficient, depending on the
purpose of the session and the people involved. The format of the
Authentication Header is 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]
INTERNET-DRAFT March 26 1997
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
is being relayed or announced via a proxy, the detailed timing
fields in the SDP description are not available to the proxy.
This is because these fields are encrypted and the proxy is not
trusted with the decryption key. Under such circumstances, SAP
includes an additional 32-bit timestamp field stating when the
session should be timed out. The digital signature in the
authentication header encompasses the time-out so that a session
cannot be maliciously deleted by modifying its time-out in an
announcing proxy. The value is an unsigned quantity giving the NTP
time [8] in seconds at which time the session is timed out. It is
in network byte order
Text Payload
When there is no encryption, the encryption bit is not set and
this format is as defined in the SDP [4] draft.
Encrypted Text Payload
This is present when the text payload has been encrypted. The
format is discussed in Section 3.3.
3.2 Authentication Header
3.2.1 Generic Format
The generic format of the Authentication Header is given below. We have
defined it both using the PGP and the Simple Public Key mechanisms.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=1 |P| Auth| |
|+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Format Specific Authentication Subheader |
| .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
V: Version number
The SAP Authentication Header version number is 1 for this
release.(3 bits)
Kirstein et al. Document Expiration 26 September 1997 [PAGE 10]
INTERNET-DRAFT March 26 1997
P: Padding Bit
If necessary the data in the Authentication Header is padded to be
a multiple of 32 bits and the Padding bit is set. In this case the
last byte of the Authentication Header contains the number of
padding bytes (including the last byte) that must be discarded.
Auth
The Authentication Type is a 4 bit encoded field that denotes the
authentication infrastructure the sender expects the recipients to
use to check the authenticity and integrity of the information.
This defines the format of the Authentication Subheader and can
take the values:
1 PGP 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
Header are discussed in Sections 3.2.2 and 3.2.3.
3.2.2 PGP Format
The generic description of the PGP packets is presented in [2]. For PGP
the basic Authentication Subheader comprises a digital signature packet
as below. This involves the use of a hash code, or message digest
algorithm, and a public key encryption algorithm. The format for
applying PGP to the payload for authentication purposes is discussed
below. For case 1 the Authentication Subheader contains a Digital
Signature Packet only. For cases 3 and 5 a Public Key Packet or a
Certificate Packet are also contained respectively. These are defined
in Appendix B and [2].
Digital Signature Packet:
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]
INTERNET-DRAFT March 26 1997
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]
INTERNET-DRAFT March 26 1997
EAID, the Encryption Algorithm Identifier(1 byte), specifies the
algorithm used to encrypt the digest with the originator's secret
key. Strictly speaking this field is optional as it is already
uniquely specified by the Key Identifier which points to a
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
public key of the originator. In the PKCS#7 standard the key is
identified by specifying the "issuerAndSerialNumber" of the
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
with the DA.
Time Stamp is in NTP Time Format as specified in RFC1119 [8].
Encrypted Block: The input to the digest encryption process starts
at the beginning of the Authentication Subheader and continues
until the end of the UTCTime field. If the Digest Encryption
Algorithm is rsaEncryption the block type is 01 as specified for
PEM message digest encryption in RFC1423.
If the Authentication Type is 4 or 6 then either a public key or a
certificate is included after the basic Subheader.
3.3 Encrypted Payload Format
3.3.1 Generic Format
The format of the Encrypted Payload depends on the type of encryption
used to encrypt the SDP text payload [4]. If no encryption has been
used only the Text payload is present. If encryption has been used then
the Encryption Key Identifier field points to either a triplet for
symmetric encryption or a quadruplet for asymmetric encryption.
3.3.2 Symmetric Encryption
If the Encryption Algorithm Identifier indicates use of symmetric
encryption, ie the first bit is zero, then the payload has been
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]
INTERNET-DRAFT March 26 1997
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P| 31 bit random field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| text payload |
| ....... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes
Random Field
This field is only present when payload is encrypted using
symmetric encryption and is used to perform the randomisation task
normally performed by an initialisation vector in algorithms such
as DES. This 31 bit field should contain a genuinely random
number.
P: Encryption Padding Bit
This bit indicates that the payload was padded prior to encryption.
The last byte of the encrypted payload indicates how many padding
bytes were added.
The data following the Timeout field is decrypted using the algorithm
specified above. Further details on the encryption algorithms are
given in [6, 12, 13].
3.3.3 Hybrid Encryption
If the value of the first bit of the Encryption Algorithm Identifier is
set to 1, then hybrid encryption is used; currently only those based on
PGP or Simple Public Key formats are defined for the asymmetric
portions. In these cases a Privacy Header (PH) is placed in front of
SDP stream, which contains a Session Encryption Key (SEK).
In the PGP case there is no need for the Symmetric Encryption Algorithm
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]
INTERNET-DRAFT March 26 1997
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
the Simple Public Key Format is used. In this case the Privacy Header
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NGTH | E A I D 1 | E A I D 2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Session Encryption Key |
| ............ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes
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]
INTERNET-DRAFT March 26 1997
Encrypted Session Encryption Key: This field contains the encrypted
SEK. When the Key Encryption Algorithm is rsaEncryption the block
type is specified to be 2.
3.3.6 Supported Algorithms
For the authentication the following Message Digest Algorithms are
defined. Simple Public Key Format packets can use any of the specified
types but PGP always uses MD5.
Message Digest Type Algorithm
1 MD5
2 MD2
3 SHA
For the Encryption Algorithm Identifier there are several Algorithms
supported for both Symmetric and Asymmetric Encryption. For Symmetric
Encryption the first bit is set to 0 and for Asymmetric Encryption it
is set to 1. The next 3 bits specify the Algorithm and the final four
bits denote the key size used. The following Algorithm Identifiers are
currently defined:
EAID Algorithm ALG Key Length
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
10010110 RSA/PGP 1 512 bits
10010111 RSA/PGP 1 768 bits
10011000 RSA/PGP 1 1024 bits
10011001 RSA/PGP 1 2048 bits
10100101 RSA/SPK 2 256 bits
10100110 RSA/SPK 2 512 bits
10100111 RSA/SPK 2 768 bits
10101000 RSA/SPK 2 1024 bits
10101001 RSA/SPK 2 2048 bits
The general format of the Encrypted Payload is given below. Here the
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Privacy Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted SDP Payload |
| .... .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kirstein et al. Document Expiration 26 September 1997 [PAGE 16]
INTERNET-DRAFT March 26 1997
Appendix A: Authors Addresses
Peter Kirstein, Goli Montasser Kohsari and Edmund Whelan are at
University College London and their email-ids are:
P.Kirstein@cs.ucl.ac.uk
G.Montasser-Kohsari@cs.ucl.ac.uk
E.Whelan@cs.ucl.ac.uk
Dept of Computer Science
University College London
Gower Street
London WC1E 6BT England
Kirstein et al. Document Expiration 26 September 1997 [PAGE 17]
INTERNET-DRAFT March 26 1997
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]
INTERNET-DRAFT March 26 1997
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]
INTERNET-DRAFT March 26 1997
Acknowledgements
SAP and SDP were originally based on the protocol used by the sd
session directory from Van Jacobson at LBNL. The design of SAP was
funded by the European Commission under the Esprit 7602 "MICE" project,
and the Telematics 1007 "MERCI" project.
References
[1] M.Handley `SAP: Session Announcement Protocol'' INTERNET-DRAFT,
draft-ietf-mmusic-sap-00.txt, 11/27/1996.
[2] D.Atkins, '' PGP Message Exchange Formats'' , RFC 1991, August
1996.
[3] PKCS#7, Cryptographic Message Syntax Standard, RSA Laboratories,
Version 1.5, November 1993
[4] M.Handley, V. Jacobson, ``SDP: Session Description Protocol'',
INTERNET-DRAFT, draft-ietf-mmusic-sdp-02.txt, 11/27/1996.
[5] R. Housley , W. Ford , T. Polk Internet public Key Infrastructure
INETRNET- DRAFT, draft-ietf-pkix-ipki-part1-03.txt December 1996.
[6] National Bureau of Standards, Data Encryption Standard, Federal
Information Processing Standards Publication 46, January 1977
[7] P. Deutsch, ``GZIP file format specification version 4.3'', RFC
1952, May 1996.
[8] D. Mills, ``Network Time Protocol version 2 specification and
implementation", RFC1119, 1st Sept 1989.
[9]X.208 Specification of
Abstract Syntax Notation One (ASN.1) ITU-T Recommendations 1988
[10] PKCS #1 RSA Encryption Standard RSA Laboratories, Version 1.5,
November 1993
[11] H. Schulzrinne, ``RTP Profile for Audio and Video Conferences with
Minimal Control'', RFC 1890, January 1996
[12] P. Metzger, P. Karn, W. Simpson, The ESP Information Triple
DES-CBC Transformation, 10/02/1995 RFC850
[13] ANSI X3.92-1981. American National Standards Data Encryption
Algorithm. American National Standards Institute, Approved 30
December 19990
[14] For details of ENTRUST see http://www.entrust.com/ [15] For
details of SECUDE see http://www.darmstadt.gmd.de/secude/
Kirstein et al. Document Expiration: 26 September 1997 [PAGE 20]
