[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 03 04                                                   
Internet Draft                                          Peter Kirstein
IETF MMUSIC WG                                  Goli Montasser-Kohsari
March 26, 1997                                          Edmund Whelan
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.


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


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

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
 -  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

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

  - 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)       |
    |                    ..................                         |


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

    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

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.


     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.


    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
        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

                         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                           |
    |                    ..                                         |


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                           |
    |                            .......                            |


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

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:

     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                      |
    |              ............                                     |


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:


        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 <>)


    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

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


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.

[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

[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]