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