Internet Draft						Peter Kirstein
IETF Engineering Task Force                                MMUSIC WG					Goli
Internet Draft                                               P. Kirstein
draft-ietf-mmusic-sap-sec-01.txt                    G. Montasser-Kohsari
March 26,
July 29th 1997                         			Edmund                                                 E. Whelan
<draft-ietf-mmusic-sap-sec-00.txt>
Expires September 26, 1997
Expires: January 29th 1998                     University College London

    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
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 ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

Distribution of this document is unlimited.

				Abstract

				ABSTRACT

The Session Announcement Protocol (SAP) is has been 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 DES, 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]

Glossary
                             GLOSSARY

   ASN      Abstract Syntax Notation
   CT       Content Type
   CTB      Cipher Type Byte
   DA       Digest Algorithm
   DEA      Digest Encryption Algorithm
   DES      Data Encryption Standards
   EAID     Encryption Algorithm Identifier
   EK       Encryption Key
   EKID     Encryption Key Identifier
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
   PK       Public Key
   PKCS     Public Key Cryptographic System
   PKCS     Public Key Cryptography Standard (as in PKCS#7)
   SAP      Session Announcement Protocol
   SDP      Session Descriptor Protocol
   SEK      Session Encryption Key
SGK
   SK       Secret Key
   SGK      Group Key
   SHA             Secure      Hash Algorithm

Kirstein et al.       Document Expiration 26 September 1997                                                [PAGE  2]

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 are 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 or PKCS#7
format security and possible future implementation plans. [3].
The SAP document also provides for the confidentiality services required
for the
SAP SDP payload [4], which describes the conference set-up
parameters. This document describes how hybrid both symmetric and public hybrid
symmetric/public key encryption algorithms should be used to provide
private announcements.

Much of this document is concerned with security considerations; these
security considerations which
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 Announcements

2.1  Introduction

It is necessary to provide authentication and integrity of the Session
Announcement to ensure that only authorised persons modify Session
Announcements and to provide facilities for announcing securely
encrypted sessions - providing the relevant proposed conferees with the
means to decrypt the data streams. The Session Announcements are made to
announce to all potential conferees the existence of a conference. It
has, however, another function - to try to minimise conflicts for Mbone
resources by spreading out the number of simultaneous conferences. Thus
there are a number of threats which we must try to address in the
securing of the Session Announcement, and some constraints. These
include the following:

  - Authentication and Integrity of Session Announcement

Here it is necessary to ensure that the Session Announcement comes from
the person claimed, and is indeed an authorised announcement. Since
subsequent announcements will modify caches of future conferences, it is
possible otherwise to spoof an original announcement, and thereby at
least cause a Denial of Service attack;

Kirstein et al.    Document Expiration 26 September 1997     [PAGE 3] attack

  - Confidentiality of Conference Details for Session Announcement

Here it is at least necessary to hide the details of the tools addresses and
media formats used.  Because of the desire In order to minimise schedule conflicts, conflicts; it is
desirable to keep at least the time of a conference known, even if all
other details are concealed.

Kirstein et al.                                                [PAGE  3]

Three types of announcement will be are supported:  unsecured,
authenticated, authenticated 'unsecured', 'authenticated'
and encrypted. The authenticated 'authenticated and encrypted'. The 'unsecured' type is described in
the
authenticated SAP specification [1] and encrypted so only the latter two 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  Symmetric and Asymmetric Encryption

The simplest versions of encryption used are symmetric ones; here the announcement is calculated by the announcement
originator.  The originators secret
same encryption key 'a' is used to encrypt the message
digest and an electronic timestamp, thus forming decrypt a digital signature,
or signature certificate. The originator sends the digital signature
along with the message; message. This
means that, if E{a,M) is the receiver receives operation of encrypting the message and M with
the
digital signature, key a and recovers algorithm E, then the operation E{a, E{a, M}} reproduces
the original message digest from the
digital signature by decrypting it with M. Because this form of encryption relies on the sender's public key. The
sender and receiver computes a new message digest from having 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 same key, it came
from the originator who owns the public key cannot be used to check the
signature.

The digital signature service involves the use for
authentication. An alternative form 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 asymmetric
encryption. Here two keys, 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 b, are used. When these are pre-pended used one
after the other to encrypt a message the
    payload original message is obtained.
Mathematically, these keys and the receiver decrypts encryption algorithm E have the hash code using
property that E{a, E{b, M}} and E{b, E{a, M}} both produce the public key
    received. original
message  M -  the receiver generates a new hash code for the received payload
    and timestamp and compares 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 decrypted hash code. If the
    two match, keys, say the payload Public
Key (PK), is accepted as authentic.

To save space published in some way while the announcement message, optionally only other, the Secret Key (SK),
is kept secret.  Using such a public key
identifier need be included; PKCS, it is then assumed that the public key
identifier, possible to achieve both
confidentiality and the public key, have been distributed previously, or
can be retrieved from authentication. Encrypting a cache or directory.  Provided message with the
recipient's Public Key
already exists in such a form, or is distributed ensures confidentiality as only the recipient
with the announcement,
one corresponding SK can be sure that decrypt the same originator message. Encrypting a message
with the SK of the sender ensures authentication as only the sender
could have sent the announcement. Only if message initially whereas anybody having access to
the full public key information, and a Certificate Authority
infrastructure, are accessible [5], Public Key can verify that it was indeed sent by the originator be identified.

Kirstein et al.    Document Expiration 26 September 1997    [PAGE 4]

2.3  Encrypted Announcements

2.3.1 Use of Symmetric Encryption

Algorithms Announcements may be encrypted person holding
the corresponding Secret Key.

Two complete systems, which can achieve both authentication and
confidentiality using a symmetric encryption
stage to provide security. If this mechanism is particular PKCS systems, are PGP [2] and PKCS#7
[3]; similar mechanisms are used, a random Session
Encryption Key (SEK) must be generated but different encryption algorithms
and conveyed in advance to formats are used. The differences between the
intended participants of a conference group.  This process takes place

out-of-band algorithm and is not described format
details for these two systems are elaborated in this draft. Session Sections 3.2 and 3.3.

2.3  Authenticated Announcements

In order to send authenticated announcements
may then be made it is possible to use the appropriate session announcement address,
encrypted so that they can
algorithms of either PGP [2] or the PKCS#7 [3] systems.  The resulting
format will be decrypted only by recipients previously
authorised by being provided with substantially different; the SEK. Many symmetric encryption
algorithms, e.g. DES [6], exact details are known to be easy to break. For this
reason, and to improve security, a set of SEKs may be distributed
out-of-band, given in
Sections 3.2 and the recipients may then try to decrypt 3.3. For each format, the announcement by trying each originator
calculates a message digest of the set of SEKs. To improve announcement.  The originator's
secret key is used to encrypt the
efficiency of this process, message digest, together with an Encryption Key Identifier (EKID), and an
Encryption Algorithm Identifier (EAID) are normally distributed
electronic timestamp, thus forming a digital signature. The originator
sends the digital signature along with the SEK. This (EKID, EAID, SEK) triplet uniquely identifies message; the
mechanism receiver
receives the message and parameters required to decrypt the Session Announcement.
Use of Key Identifiers is undesirable if different sessions are to be
announced using digital signature, and recovers the same DES
original message digest from the digital signature by decrypting it
with the sender's public 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 receiver computes a new message
digest from the authorised parties prior message, and checks to see if it matches the reception of the SAP
announcement. The process of ensuring one
recovered from the receipt, managing digital signature. If it matches, then this is

Kirstein et al.                                                [PAGE  4]

considered adequate proof that the cache,
and trying several keys can be relatively complex message was not altered, and expensive; for
this reason that it
came from the number of originator who owns the public key used to check the
signature.

Each Session announcement contains a message ID hash [4]. The
specifications for SAP announcements [1] states that such triplet announcements
may be repeated frequently, but that if any change is made in the
announcement, a different message ID must be distributed should used; as a result, a
different message ID hash will be minimised. One mechanism for minimising appended to the number of triplet
required message. As a result,
it is only necessary to use Public Key Cryptography as authenticate an announcement the first time it
is received.

To save space in the Authenticated
Announcements of Section 2.2. announcement message, only a public key identifier
is generally included. It would be possible to use these
encryption algorithms on is then assumed that the whole announcement message; this would,
however, public key itself
has either been distributed previously or can 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 retrieved from a combination of symmetric and cache
or directory. Optionally the Public Key algorithms.
Now a random Session Encryption Key (SEK) is generated as itself can be included in Section
2.3.1. A Privacy Header (PH) is constructed containing the SEK, which
is encrypted with
announcement removing the need for prior distribution.  Consequently,
providing that 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 is already available in a local cache or
Directory, or is distributed only once as long as with the group membership does not change; it is possible to re-use announcement, one can be sure that
the same
group keys for many sessions, with different SEKs. This minimises originator sent the
number of times announcement. Only if the prior full public key distribution sequence must be followed.

Kirstein et al.    Document Expiration 26 September 1997    [PAGE 5]

It should be noted that because
information, and a Group Key is used in Certificate Authority infrastructure, are accessible
[5], can the above, originator be identified.

2.4  Authenticated and Encrypted Announcements

2.4.1  Introduction

When it is
not possible to use the same Header desired to authenticate the sender
uniquely; though make private announcements, it is authenticated automatically that necessary to
encrypt the sender is
one set-up details of the group which has reserved the asymmetric conference. The normal way of
providing such encryption key
pair.  By using a different Authentication Key for the authentication
of Section 2.2 from is to use only a symmetric encryption
algorithm such as the Data Encryption Keys of Standard (DES [6]) to encrypt
such a session using a Session Encryption Key (SEK); this section, it algorithm is possible
to still authenticate
used because other systems, such as the identity 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 sender.

2.3.3  Encrypting Announcements

We will now provide SEK
must be securely distributed to all authorised recipients.

2.4.2  Distribution of Session Encryption Keys

There are various ways that the SEK could be distributed; all rely on
distributing some more detail.  If shared secret in advance to the payload intended participants
in the conference group.  When this process takes place out of band, it
is not described further in this document.

Many symmetric encryption algorithms, e.g. DES [6] are known to be
compressed, this is performed prior easy
to encryption .

When an announcement break; with such algorithms, it is undesirable to be encrypted, re-use the payload is encrypted using
symmetric encryption. In SEK many
times. For this case reason, and to improve security, a set of SEKs may be
distributed out-of-band; the recipients may then try to decrypt the
announcement by trying each such encryption key of these SEKs in turn.

As in Section 2.3, one may use the fact that if any change is used
only once; made in
the announcement, a new Session Encryption Key (SEK) different message ID, and hence message ID hash is generated as a random
number for each announcement. Since
used; it is to be used only once, the SEK
is bound necessary to the attempt to decrypt an announcement message and transmitted with
the first time it in a Privacy Header.
The sequence is as follows: received. The Privacy Header contains the SEK,
encrypted basic symmetric system is contained

Kirstein et al.                                                [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 groups Public Group Key, together with potential weakening of the groups 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 Identifier (PGKID).  This 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 followed by one mechanism for minimising the encrypted
Payload.

2.3.4  Decrypting need for
secure transmission of shared secrets; this was already used in the
Authenticated Announcements

Upon receiving a new of Section 2.2. It would be possible to use
these encryption algorithms on the whole announcement with message but this
would be inefficient because the asymmetric encryption bit set, a
receiver should attempt to decrypt algorithms
normally use much longer encryption keys, and are much more resource
intensive, than the announcement with its group
private key or its own private key - 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 indicated by in Section 2.4.1. A
Privacy Header (PH) is constructed containing the PGKID.

The sequence SEK, which is as follows:

  - The receiving participants derive
encrypted with the asymmetric encryption algorithm. It is now only
necessary to distribute a 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
(PGK) i.e. {SGK, PGK} to 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 SEK. However, this pair needs to decrypt be
distributed only once as long as the
    encrypted text payload.

Note that if an encrypted announcement group membership does not change;
it is being announced via a proxy,
then there may be no way possible to re-use the same group keys for many sessions, with
different SEKs. This minimises the proxy to discover number of times the prior key
distribution sequence must be followed.

It should be noted that because a Group Key is used in the
announcement has been superseded, and so above, it may continue is
not possible to relay use the
old announcement in addition same Header to authenticate the new announcement. SAP provides no
mechanism to chain modified encrypted announcements, so sender uniquely,
though it is advisable
to announce authenticated automatically that the unmodified session as deleted for a short time after sender is one of the modification
group which has occurred. This does not guarantee that all proxies
have deleted reserved the session, and so receivers of encrypted sessions should
be prepared asymmetric encryption key pair.  It is
still possible to discard old versions authenticate the identity of session announcements that they
may receive (as identified by the SDP version field). In most cases
however, sender by using a
different Authentication Key for the only stateful proxy will Authentication Header as described
in Section 2.3.

It would be local possible to (and known to) the
sender, use a similar technique using symmetric
encryption with a strong encryption algorithm 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]

2.3.5 Encryption Algorithm encryption key
Identifier (EAID)

This is an 8-bit integer which is mentioned in Sections 2.3.1 and
2.3.2. It is distributed with instead of the Public Key ID in Group Key, However, we believe the form of: {Encryption
Public Key ID, Encryption Algorithm ID, Encryption Key(s)}

It is used for three purposes: method to determine whether symmetric or
asymmetric encryption be superior so this variant is used, to specifiy not pursued.

2.4.4  Encrypting Announcements

We will now provide some more detail.  If the encryption algorithm,
and payload is to specify the encryption key length. For be
compressed, 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 performed prior to encryption.

When an announcement 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 to be achieved encrypted, the payload is encrypted using PGP [2]
or Simple Public Key format packets.  These formats are explained in
greater detail below.
symmetric encryption. In Section 3.1 we discuss the generic packet
format defined in [1]; this case each such encryption key is still used only at the draft stage, so any
changes in
once; a new Session Encryption Key (SEK) is generated as a random number
for each announcement. Since it will have is to be tracked in future versions of this
document. In Section 3.2 we consider used only once, the formats of SEK is
bound to the Authentication
Header, message and transmitted with it in Section 3.3 that of a Privacy Header. The
sequence is as follows: The Privacy Header contains the Text Payload.

It would be possible to define our own versions of the packets
completely for this application. In that case SEK, encrypted
with the formats would be
simpler, but all group's Public Group Key, together with information identifying

Kirstein et al.                                                [PAGE  6]

the implementations would have Group Key which has been used. The encrypted Payload is appended to be coded using
the
basic encryption libraries, and Privacy Header.

2.4.5  Decrypting Announcements

Upon receiving 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 announcement with the encryption bit set, a
receiver should attempt to ease decrypt the
eventual implementation, while simplifying announcement with the formats relevant
group private key or their own private key as far indicated in the Privacy
Header.  The sequence is as
possible within such a constraint. There follows:

    1. Prior to the announcement, the group's Public/Secret Group Key
       pair is an additional advantage distributed securely.

    2. From the announcement, the receiving participants determine
       which Public Group Key has been used by looking at the
       information contained in
this approach; it will be possible the Privacy Header.

    3. They then decrypt the Session Encryption Key (SEK) with the SGK
       corresponding to send session announcements by the PGK identified in Step 2 and obtain other
       necessary information such as the content encryption algorithm
       from the Privacy Header.

    4. The authorised receivers decrypt the encrypted Session Invitation Protocol or by electronic mail text payload using PGP
or S-MIME,
       the SEK and re-use much of the same code as with SAP.

Kirstein et al.    Document Expiration 26 September 1997    [PAGE 7]

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]

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

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 relevant symmetric content encryption algorithm,
       which was used to encrypt the certificate included

The specific formats payload.

Note that if an encrypted announcement is being announced via a proxy,
then there may be no way for the PGP and Simple Public Key variants of proxy to discover that the
Header are discussed in Sections 3.2.2 announcement
has been superseded, and 3.2.3.

3.2.2 PGP Format

The generic description of so it may continue to relay the PGP packets is presented old
announcement 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 addition to the payload for authentication purposes new announcement. SAP provides no
mechanism to chain modified encrypted announcements, so it is discussed
below. For case 1 advisable
to announce the Authentication Subheader contains a Digital
Signature Packet only. For cases 3 and 5 a Public Key Packet or unmodified session as deleted for 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 short 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 after
the MD output, used as a checksum (2 bytes);

     i) a byte string of encrypted data holding modification has occurred. This does not guarantee that all proxies
have deleted the RSA-signed digest.

     The length session, and so receivers of field (a) depends on the size encrypted sessions should
be prepared to discard old versions of session announcements that they
may receive (as identified by the key used for
     signing. If 512, 768 or 1024 then SDP version field). In most cases
however, the length only stateful proxy will be 2 ,3 or 5
     respectively. The first byte is Cipher Type Byte (CTB) local to (and known to) the
sender, and its
     value is 10001000 for key size 512, 10001001 an additional (local-area) protocol involving a handshake
for key size 768 such session modifications can be used to avoid this problem.

3.  Secured SAP Packet Formats

Both Authentication and
     10001010 for key size 1024. The remaining 1,2 Privacy can be achieved using PGP [2] or 4 bytes of PKCS#7
[3] format packets. In Section 3.1 we discuss the generic packet structure field gives format
defined in SAP [1]. In Section 3.2 we consider the length formats of the packet.

     The length
Authentication Header, and in Section 3.3 that of RSA signed digest the encrypted payload.

It would be possible to define our own versions of (i) the packets for this
application. In that case the formats would be simpler, but all the
implementations would have to be coded using the basic encryption
libraries, and a new infrastructure would have to be defined. Both PGP
and PKCS#7 already have complete implementations and, by using their
formats, several application tool kits are already available (e.g.
Entrust [14], Secude [15]). In addition, these formats also depends on have

Kirstein et al.                                                [PAGE  7]

complete infrastructures defined around them. For these reasons, we have
chosen to retain enough compatibility to ease the eventual
implementation, while simplifying the size of 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 key used. For keys 512, 768 encrypted Session
Invitation Protocol or 1024 the size is 64, 96 by electronic mail using PGP or 128
     bytes respectively

3.2.3 Simple Public Key Format

The generic description S-MIME, and
re-use much of the PKCS#7 same code as with SAP.

3.1  Secured SAP Packet Format

The SAP data packets is presented as defined in [3]. For
the Simple Public Key format [1] has the basic Authentication Subheader is as
follows: 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | DA    | E A I D   | V=2 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MT  |E|C| Header Length |                   64       16 bit key identifier Message ID Hash  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    ..                     Originating Source                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
    |                    128 bit payload digest              Authentication Header (Optional)                 |
    |                    ..                    ..................                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Time Stamp               32 bit Time-Out Field (Optional)                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Encrypted block              Text Payload (Possibly Encrypted)                |
    |                    ..                    ..................                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes

DA,

Notes:

Version Number, V: This is a 3-bit field and has the Digest Algorithm Identifier (5 bits), specifies value 2 for this
  version of SAP [1]

Message Type, MT: This defines the
    algorithm used to digest contents of the data. This payload and can currently have be

      0. Session Descriptor Announcement Packet in which case the
    following values:

        1 - RSA's MD2 algorithm
         payload is an SDP session description as defined described in RFC 1319.
	2 - RSA's MD5 algorithm as defined [4]

      1. Session Description Deletion Packet in RFC 1321
        3 - The SHA Secure Hash Algorithm

Kirstein et al.    Document Expiration 26 September 1997   [PAGE 12]

EAID, which case the payload
         is a singleSDP line containing the origin field of the
         announcement to be deleted

Encryption Algorithm Identifier(1 byte), specifies Bit, E: -. If this is set, the text payload has been
  encrypted

Compression Bit, C: If this is set the payload has been compressed using
  the gzip compression utility [7]

Header length: This is an 8 bit unsigned quantity giving the
    algorithm used to encrypt number of
  32 bit words following the digest with main SAP header that contains the originator's secret
    key.  Strictly speaking
  authentication data. If this field is optional as it is already
    uniquely specified by non-zero, the Key Identifier which points to a
    quadruplet which has already been distributed out-of-band. It payload is
    repeated here solely for compatibility reasons.

    Key
  authenticated, and an Authentication Header is present

Kirstein et al.                                                [PAGE  8]

Message Identifier (EKID) Hash: This is a 16 bit quantity that, when used in
  combination with the 64 least significant bits of originating source, provides a globally unique
  id identifying the
    public key precise version of this announcement.  The message
  id hash should be changed if any field of the originator. In the PKCS#7 standard the key session description is
    identified by specifying the "issuerAndSerialNumber"
  changed.  A value of zero means that the
    certificate containing hash should be ignored and
  the public key. message should always be parsed.

Originating Source: This has two fields namely 32-bit field gives the Distinguished Name IP address of the Certificate Issuer and the serial
    Number
  original source of the Certificate. The Distinguished Name can message.  It is permissible for this to be
    arbitrarily long, being zero
  if the message has not passed through a sequence of Relative Distinguished Names, proxy relay and if the Serial Number message
  id hash is simply an integer. also zero. This was considered is intended for backward compatibility with
  SAPv0 clients only.

Authentication Header: This can be used for two purposes:

      1. Verification that changes to a session description or deletion
         of a session are permitted

      2. Authentication of the identity of the session creator.

In some circumstances only verification is possible because a
certificate signed by a mutually trusted person or authority is not
available.  However, under such circumstances, the session originator
can still be authenticated to be too long and the 64-bit key identifier, same 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 session originator of
previous sessions claiming to be from the digest encryption process starts
    at same person.  This may or may
not be sufficient, depending on the beginning purpose of the Authentication Subheader session and continues
    until the end
people involved. The precise format of the UTCTime field.  If the Digest Encryption
    Algorithm Authentication Header is rsaEncryption
discussed in Section 3.2.

Timeout: When the block type session payload is 01 as specified for
    PEM message digest encryption in RFC1423.

If encrypted, and the Authentication Type session
  description is 4 or 6 then either a public key being relayed or announced via a
certificate is included after the basic Subheader.

3.3 Encrypted Payload Format

3.3.1 Generic Format

The format of proxy, the Encrypted Payload depends on detailed
  timing fields in the type of encryption
used SDP description are not available to encrypt the SDP text payload [4]. If no encryption has been
used only proxy.
  This is because these fields are encrypted and the Text payload proxy is present. If encryption has been used then not
  trusted with the Encryption Key Identifier decryption key. Under such circumstances, SAP
  includes an additional 32-bit timestamp field points to either a triplet for
symmetric encryption or stating when the session
  should be timed out. The digital signature in the authentication
  header encompasses the time-out so that a quadruplet for asymmetric encryption.

3.3.2 Symmetric Encryption

If session cannot be
  maliciously deleted by modifying its time-out in an announcing proxy.
  The value is an unsigned quantity giving the Encryption Algorithm Identifier indicates use of symmetric
encryption, ie NTP time [8] in seconds
  at which time the first bit session is zero, then timed out.  It is in network byte order

Privacy Header: This is present when the text payload has been encrypted symmetrically with no use of asymmetric
  using hybrid encryption. In
addition

Text Payload: When there is no encryption, the encrypted payload has a random field added prior to encryption bit is not set
  and this format is as below: 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.

Kirstein et al.    Document Expiration 26 September 1997                                                [PAGE 13] 10]

3.2  Authentication Header

3.2.1  Generic Format

The generic format of the Authentication Header is given below. The
structure of the Format Specific Authentication Subheader, using both
the PGP and the PKCS#7 formats, is discussed in Sections 3.2.2 and 3.2.3
respectively.

                         1                   2                   3
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 V=1 |P| Auth  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header Length |                        text payload                               |
    |+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+                               |
    |              Format Specific Authentication Subheader         |
    |                            .......                       ..................                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes

Random Field

    This field

Notes:

Version Number, V: For this release the version number is only present when payload 1 (3 bits)

Padding Bit, P: If necessary the data in the Authentication Header is encrypted using
    symmetric encryption
  padded to be a multiple of 32 bits and the Padding bit is used to perform set. In this
  case the randomisation task
    normally performed by an initialisation vector in algorithms such
    as DES. This 31 last byte of the Authentication Header contains the number of
  padding bytes (including the last byte) that must be discarded.

Authentication Type, Auth: The Authentication Type is a 4 bit encoded
  field should contain a genuinely random
    number.

P: Encryption Padding Bit that denotes the authentication infrastructure the sender
  expects the recipients to use to check the authenticity and integrity
  of the information. This bit indicates that defines the payload was padded prior to encryption.
    The last byte format of the encrypted payload indicates how many padding
    bytes were added. Authentication
  Subheader and can take the values:

      1. PGP Format
      2. PKCS#7 Format
      3. PGP Format with the 'Certificate' included
      4. PKCS#7 with the Certificate included

3.2.2   PGP Format

The data following generic description of the Timeout field PGP packets is decrypted using the algorithm
specified above.  Further details on presented in [2]. For PGP
the encryption algorithms are
given basic Format Specific Authentication Subheader comprises a digital
signature packet as described in [6, 12, 13].

3.3.3 Hybrid Encryption

If [2]. This involves the value use of a hash
code, or message digest algorithm, and a public key encryption
algorithm. For the first bit of case when the Encryption Algorithm Identifier is
set to 1, then hybrid encryption Authentication type is used; currently 1 the Subheader
contains a Digital Signature Packet only those based on
PGP with the hexadecimal signature
classification being <00> or Simple <01>. The only Message Digest Algorithm is
1 (MD5) and the Public Key formats are defined for Cryptosystem (PKC) is 1, this being the asymmetric
portions. In these cases RSA
system. If the type is 3 then a Privacy Header (PH) Certificate Packet is placed in front also appended to
the previous Signature Packet. A certificate packet is composed of
SDP stream, the
following individual packets:

Kirstein et al.                                                [PAGE 11]
      (a)  A Public Key Packet which contains a Session Encryption defines the RSA public key
      (b)  A UserID packet
      (c)  A Signature Packet

The Public Key packet again has the Public Key (SEK). Cryptosystem 1. In the PGP
case there is no need for of Signature Packet (c) the Symmetric Encryption Algorithm signature classification now takes the
hexadecimal values <10> to be specified as this is always IDEA. <13>. These packets are all detailed in [2].

3.2.3 PKCS#7 Format

The formats for Format Specific Authentication Subheader will, in the PGP and
Simple Public Key PKCS#7 case,
have an ASN.1 ContentInfo type privacy headers are as below.

3.3.4 PGP Format Privacy Header

If with the value ContentType being signedData.
Use is made of the Encryption Algorithm Identifier Algorithm is 1 then option available in PKCS#7 to leave the PGP format content
itself blank as the content which is used. In signed is, in this case application,
already present as the Privacy Header text payload, whether this is composed encrypted or not.
Thus inclusion of
a Public Key Encrypted Packet. it within the SignedData type would be duplication and
increase the packet length unnecessarily. The purpose of full specification for
this packet ASN.1 type is available in [3].

 There will only be one signerInfo and related fields corresponding to convey
the one-time session key used to encrypt originator of the message SAP announcement.  Although it would be possible
to transfer the recipient

Kirstein et al.    Document Expiration 26 September 1997   [PAGE 14]

in relevant information is a secure manner. This single signerInfo type rather
than the complete ContentInfo it is done by encrypting considered preferable to use the session key
latter for two reasons. Firstly, this is compatible with
the group public key so that only a member wider range
of the group can recover the
session key. (Note applications and security toolkits and secondly, 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) certificate
can be included in a byte, giving standard way. If the version number, Authentication Type is 2 there
are no certificates or 3; (1byte)           3

     c) a number ID field, giving certificate revocation lists whereas if the ID
authentication type is 4 the originator's X.509 certificate is added in
the certificate field of a key; (8bytes)

     d) a byte, giving a PKC number; (1byte)         (1      RSA)

     e) a byte string this type.

In addition, for both type 2 and 4, use is made of encrypted data (DEK).  (64, 96 or 128 bytes)

3.3.5 Simple Public Key Format Privacy Header

If the value ability in PKCS#7
to authenticate various attributes as specified in PKCS#9 [16]. The
authenticatedAttributes field of the Encryption Algorithm Identifier Algorithm SignerInfo type is 2 then used and the Simple Public Key Format
attribute which is authenticated is used. In this case the Privacy Header SigningTime.  This 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) a
mandatory field in this specifies the length specification.

3.3	Encrypted Payload Format

3.3.1	Generic Format

The format of the Privacy Header

EAID1, the (asymmetric) Encryption Algorithm Identifier (1 byte)
   identifies Encrypted Payload depends on the asymmetric algorithm type of encryption
used to encrypt the Session
   Encryption Key (SEK). The values this can take are specified in
   Section 3.3.6. Strictly speaking this SDP text payload [4]. If no encryption has been used
only the Text payload is not necessary as it present.

If encryption has
   already been completely specified by used then the Key Identifier encryption bit in the main SAP header. It
header is duplicated here for compatibility reasons.

EAID2, the (symmetric)Encryption Algorithm Identifier (1 byte)
   identifies set  and the payload is encrypted either symmetrically or
using hybrid encryption. For symmetric algorithm used to encrypt encryption the content. 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
   values 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 can take are specified in Section 3.3.6. case there is a

Kirstein et al.    Document Expiration 26 September 1997                                                [PAGE 15]

Encrypted Session Encryption Key: This field contains the encrypted
   SEK. When the Key Encryption Algorithm is rsaEncryption the block
   type is specified 12]

very specific format 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 first byte 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 Privacy header, which
follows other time-out field in this case.

3.3.2	Symmetric Encryption

If symmetric encryption alone has been used then the first bit is set to 0 and for Asymmetric Encryption it
is set encrypted payload
has a random field added prior to 1. The next encryption as below.

                         1                   2                   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
     0 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 6 7 8 9 0 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 3 4 5 6 7 8 9 0 1 2            2048 bits 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
  tasks normally performed by an initialisation vector in algorithms
  such as DES. This 31-bit field should contain a genuinely random
  number.

Padding Bit, P: This bit indicates that the payload was padded prior to
  encryption. The general format last byte of the Encrypted Payload encrypted payload indicates how many
  padding  bytes were added.

The data following the Time-out field is decrypted using the algorithm
specified above. Further details on the encryption algorithms are given below. Here
in [6, 12, 13].

3.3.3	Hybrid Encryption

If a combination of asymmetric and symmetric encryption has been used
then the
format part of the SAP packet following the time-out field has the
following structure. This effectively takes the form of a Privacy Header depends header
followed by the encrypted SDP payload, the precise format depending on
whether PGP or Simple Public
Key (SPK) format is PKCS#7 formats have been used. The Encrypted Text Payload is the result specific details for
each 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]

Appendix A: Authors Addresses

Peter Kirstein, Goli Montasser Kohsari and Edmund Whelan these formats 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]

Appendix B: PGP format

Public key Packet

    a) Packet structure field (2 3 5 bytes)                 100110 (As
    defined described in 1)

    b) version number = Sections 3.3.3.1 and 3.3.3.2
respectively.

Privacy Header:

                         1                   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)
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | V=1 |P| Type  | Header Length |                               |
    |+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+                               |
    |                  Format Specific Privacy Subheader            |
    |                       ..................                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Notes

Version, V: In this version the Version of the SAP
header protocol.  This would enable compatibility between information
contained privacy Header is 1

Padding Bit, P: If necessary the data in the  Authentication Subheader Privacy Header is padded to
  be a multiple of 32 bits and S/MIME MUAs for example. the Padding bit is set. In this version case the
  last byte of the  standard it was considered that, although we
wanted to follow Privacy Header contains 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 number of padding bytes
  (including the main document follows last byte) that must be discarded.

Format Type, Type: This can be either 1 for PGP or 2 for PKCS#7  in principle as it
contains similar fields. One difference format.

3.3.3.1  PGP Format Privacy Header

For the case when the Format Type is 1 the use Format Specific Privacy
Subheader is composed of a PGP Public Key Identifier
rather than "issuerAndSerialNumber" as detailed above. Also, Object
Identifiers were not used here.

In encrypted packet and the text
payload is a PKCS#7 compliant SAP protocol it would be expected that PGP  Conventional Key Encrypted Packet. These are detailed
in [2]. The Public Key Cryptosystem is 1, this being defined as the
Authentication Subheader would consist of an ASN.1 SignerInfo RSA
system, and the only supported symmetric encryption algorithm is the
IDEA algorithm, corresponding to the Conventional encryption 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  } byte
value of 1.

3.3.3.2	PKCS#7 Format Privacy Header

If the Authentication  Type is "4"  (PKCS#7 + public key) the public key
would be appended to 2 then the Authentication Subheader. This Format Specific Privacy Header is in composed of
a form
equivalent to that defined PKCS#7 ContentInfo type with the ContentType being envelopedData.
These are detailed in PKCS#1 as:

RSAPublicKey ::= SEQUENCE {
       modulus         INTEGER
       publicExponent INTEGER }

If [2]. In this case the Authentication Type Text Payload, which has been
symmetrically encrypted with the algorithm specified in the
contentEncryptionAlgorithm field, is "6" (PKCS#7 + certificate) effectively the
certificate would encryptedContent
part of the structure. There will be appended only one recipientInfo structure
corresponding to the Authentication Subheader. This
Certificate group certificate, which has been previously
distributed. The contentType in the EncryptedContentInfo structure is an ASN.1 type as
"Data".

3.3.4	Supported Algorithms

In the case of the hybrid encryption the algorithms supported are
defined in X.509.

If asymmetric encryption is used a [2,3] for PGP and PKCS#7 compliant Privacy Header
would consist respectively. The details of the
algorithms used are an ASN.1 RecipientInfo inherent part of the information sent in the
Privacy Header and EncryptedContentInfo type Authentication Header and so it is not necessary to
specify in advance which are supported; this is open to change as below:

RecipientInfo ::= SEQUENCE {
     version                         Version,
     issuerAndSerialNumber           IssuerAndSerialNumber,
     keyEncryptionAlgorithm          KeyEncryptionAlgorithmIdentifier,
     encryptedKey                    EncryptedKey }

EncryptedContentInfo ::= SEQUENCE {
     contentType                     ContentType,
     contentEncryptionAlgorithm    ContentEncryptionAlgorithmIdentifier,
     encryptedContent              [0] IMPLICIT EncryptedContent OPT } new
algorithms arise and older ones are shown to insecure.

For the purely symmetric encryption case then currently only DES is
supported with a 56-bit Key length.

Kirstein et al.    Document Expiration 26 September 1997                                                [PAGE 19] 14]
                   Appendix A: Authors' Addresses

  Peter Kirstein, Goli Montasser Kohsari and Edmund Whelan are at
  University College London and their contact details are:

        P.Kirstein@cs.ucl.ac.uk            Tel: +44 71 380 7286
        G.Montasser-Kohsari@cs.ucl.ac.uk   Tel: +44 71 380 7215
        E.Whelan@cs.ucl.ac.uk              Tel: +44 71 419 3688

	Dept of Computer Science           Fax: +44 71 387 1397
        University College London
        Gower Street
        London WC1E 6BT England

                         Acknowledgements

SAP and SDP were originally based on the protocol used by the sd session
directory from Van Jacobson at LBNL. The design of SAP was
funded by the European Commission under the
Esprit 7602 "MICE" project, and the Telematics 1007 "MERCI" project. project
funded the design of SAP.

Kirstein et al.                                                [PAGE 15]
                            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 Public Key  Infrastructure
    INETRNET-
    INTERNET- DRAFT, draft-ietf-pkix-ipki-part1-03.txt December 1996.

[6] National Bureau of Standards, Data Encryption Standard, Federal
    Information Processing Standards Publication 46, January 1977

[7] P.  Deutsch, ``GZIP file format specification version 4.3'',
    RFC 1952, May 1996.

[8] D. Mills, ``Network Time Protocol version 2 specification and
    implementation", RFC1119, 1st Sept 1989.

[9]X.208

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

[14] For details of ENTRUST see http://www.entrust.com/

[15] For  details of SECUDE see http://www.darmstadt.gmd.de/secude/

[16] PKCS#9 Selected Attribute Types,
     RSA Laboratories, Version 1.1, November 1993

Kirstein et al.   Document Expiration:  26 September 1997                                                [PAGE 20] 16]