HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 01:36:18 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 05 Jul 1994 22:00:00 GMT ETag: "2ed65c-a30b-2e19d7e0" Accept-Ranges: bytes Content-Length: 41739 Connection: close Content-Type: text/plain Internet Draft C. Adams, Bell-Northern Research draft-ietf-cat-spkmgss-00.txt June 20, 1994 The Simple Public-Key GSS-API Mechanism (SPKM) 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Comments on this document should be sent to "cat-ietf@mit.edu", the IETF Common Authentication Technology WG discussion list. ABSTRACT This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFCs 1508 and 1509) when using the Simple Public-Key Mechanism. BACKGROUND Although the Kerberos Version 5 GSS-API mechanism is becoming well- established in many environments, it is important in some applications to have a GSS-API mechanism which is based on a public- key, rather than a symmetric-key, infrastructure. One such mechanism was described as part of the Distributed Authentication Security Service (DASS) in [RFC-1507]. However, the mechanism described in this document has been proposed as an alternative to the DASS mechanism for several reasons. 1) The SPKM is simpler than DASS, containing no non-essential functionality. 2) The SPKM allows three-way mutual authentication, whereas DASS uses two-way mutual authentication; this enables environments which do not have access to secure timestamps to nevertheless have access to secure mutual authentication. Adams Document Expiration: 31 December 1994 1 3) The SPKM uses Object Identifiers to specify various algorithms to be used by the communicating peers. This allows maximum flexibility for a variety of environments, for future enhancements, and for alternative algorithms. 4) The SPKM allows the option of a true, asymmetric algorithm- based, digital signature in the gss_sign() and gss_seal() operations, whereas DASS uses an integrity checksum based on a MAC computed with a symmetric algorithm (DES). For some environments, the availability of true, non-repudiable digital signatures is a necessity. 5) SPKM data formats and procedures are designed to be as similar to those for the Kerberos mechanism as is practical. This is done for ease of implementation in those environments where Kerberos has already been implemented. For the above reasons, it is felt that the SPKM will offer greater flexibility and functionality than DASS, without undue complexity or overhead. KEY MANAGEMENT The key management employed in SPKM is intended to be as compatible as possible with both X.509 [X.509] and PEM [RFC-1422], since these represent large communities of interest and show relative maturity in standards. ACKNOWLEDGMENTS Much of the material in this document is based on the Kerberos Version 5 GSS-API mechanism [KRB5], and is intended to be as compatible with it as possible. This document also owes a great debt to Warwick Ford of Bell-Northern Research for many fruitful discussions and to John Linn of OpenVision Technologies for helpful comments. Adams Document Expiration: 31 December 1994 2 1. OVERVIEW The SPKM is a mechanism for authentication, key establishment, data integrity, and data confidentiality in an on-line distributed application environment using a public-key infrastructure. This mechanism conforms to the interface defined by the Generic Security Service Application Program Interface [RFC-1508] and can therefore be used as a drop-in replacement by any application which makes use of security services through GSS-API calls (for example, any application which already uses the Kerberos GSS-API for security). The use of a public-key infrastructure allows, among other things, non-repudiable digital signatures to be employed for message exchanges. Note that this document defines two separate mechanisms, SPKM-1 and SPKM-2, which are identical except that SPKM-2 requires the presence of secure timestamps for the purpose of replay detection during context establishment and SPKM-1 does not. This allows greater flexibility for applications since secure timestamps can not always be guaranteed to be available in a given environment. 2. ALGORITHMS A number of algorithm types are employed in SPKM. Each type, along with its purpose and a set of specific examples, is described in this section. 2.1 Integrity Algorithm (INT_ALG): Purpose: This algorithm is used to ensure that a message has not been altered in any way after being constructed by the legitimate sender. Depending on the algorithm used, the application of this algorithm may also provide authenticity and non- repudiability for the message. Examples: md5WithRSA OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 3 } This algorithm provides data integrity and non-repudiation by computing an RSA signature on the MD5 hash of that data. Note that this is equivalent to md5WithRSAEncryption {1 2 840 113549 1 1 4}, which is defined in [PKCS]. Adams Document Expiration: 31 December 1994 3 DES-MAC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 10 } This algorithm provides data integrity by computing a DES MAC (as specified by [FIPS-113]) on that data. DES-CBC OBJECT IDENTIFIER ::= { -- used only for gss_seal() iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 7 -- carries IV as a parameter } This algorithm provides data integrity by encrypting that data using DES-CBC mode. At the receiving end, if the decrypted data is correctly padded AND the decrypted sequence number is correct, then the data was not altered. 2.2 Sequence Algorithm (SEQ_ALG): Purpose: This symmetric algorithm is used to construct the encrypted sequence number for a token. Because it makes use of both the (plaintext) sequence number and the integrity checksum, an invalid message with a valid sequence number, and a valid message with an invalid sequence number will both be detected. Examples: DES-CBC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 7 -- carries IV as a parameter } 2.3 Confidentiality Algorithm (CONF_ALG): Purpose: This symmetric algorithm is used to generate the encrypted data for gss_seal(). Examples: DES-CBC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 7 -- carries IV as a parameter } Adams Document Expiration: 31 December 1994 4 2.4 Key Establishment Algorithm (KEY_ESTB_ALG): Purpose: This algorithm is used to establish a symmetric key for use by both the initiator and the target over the established context. This context key may be used as the encryption / decryption key for either or both of SEQ_ALG and CONF_ALG. Examples: id-rsa-key-transport OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 22 -- imported from [X9.44] } In this algorithm, the context key is generated by the initiator, encrypted with the RSA public key of the target, and sent to the target. The target need not respond to the initiator for the key to be established. During context establishment in SPKM, the initiator offers a set of possible symmetric encryption algorithms and a set of possible integrity algorithms to the target. The symmetric algorithms selected by the target become ones that may be used for SEQ_ALG and CONF_ALG over the established context. The integrity algorithms selected by the target become ones that may be used for INT_ALG over the established context. Note that the order of the selected integrity algorithms defines the values of the Quality of Protection (QOP) parameter used in the gss_sign() and gss_seal() calls -- see Section 5.2 for further details. In future versions of SPKM, other algorithms may be specified for any or all of INT_ALG, SEQ_ALG, CONF_ALG, and KEY_ESTB_ALG. Adams Document Expiration: 31 December 1994 5 3. TOKEN FORMATS This section discusses protocol-visible characteristics of the GSS- API mechanism to be implemented atop the SPKM; it defines elements of protocol for interoperability and is independent of language bindings per [RFC-1509]. The SPKM GSS-API mechanism will be identified by an Object Identifier representing "SPKM-1" or "SPKM-2", having the value: {iso(1), org(3), dod(5), internet(1), security(5), SPKM-1(xx)} or {iso(1), org(3), dod(5), internet(1), security(5), SPKM-2(xx)}, where SPKM-1 uses 3-way mutual authentication for context establishment and SPKM-2 uses 2-way mutual authentication for context establishment. Tokens transferred between GSS-API peers (for security context management and per-message protection purposes) are defined. 3.1. Context Establishment Tokens Per RFC-1508, Appendix B, the initial context establishment token will be enclosed within framing as follows: InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE { thisMech MechType -- MechType is OBJECT IDENTIFIER -- representing "SPKM-1" or "SPKM-2" innerContextToken ANY DEFINED BY thisMech -- contents mechanism-specific } The innerContextToken of the initial context token will consist of an SPKM_REQ message, preceded by a two-byte token-id (TOK_ID) field, which shall contain the value 01 00. The above GSS-API framing shall be applied to all tokens emitted by the SPKM GSS-API mechanism, including SPKM_REP_TI, SPKM_REP_IT, SPKM_ERROR, context-deletion, and per-message tokens, not just to the initial token in a context establishment sequence. While not required by RFC-1508, this enables implementations to perform enhanced error-checking. The innerContextToken field of context establishment tokens for the SPKM GSS-API mechanism will contain a message (SPKM_REQ, SPKM_REP_TI, SPKM_REP_IT or SPKM_ERROR), preceded by a 2-byte TOK_ID field containing 01 00 for SPKM_REQ messages, 02 00 for SPKM_REP_TI messages, 03 00 for SPKM_REP_IT messages, and 04 00 for SPKM_ERROR messages. The SPKM context establishment tokens are defined according to [X.509] Section 10. SPKM-1 uses Section 10.4, "Three-way Authenti- cation", and SPKM-2 uses Section 10.3, "Two-way Authentication" when mutual authentication is requested by the initiator. Adams Document Expiration: 31 December 1994 6 Relevant SPKM_REQ syntax is as follows (note that imports from other documents are given in Appendix A): SPKM-REQ ::= [APPLICATION xx] SEQUENCE { certif_data [0] CertificationData OPTIONAL requestToken [1] REQ_TOKEN } CertificationData ::= SEQUENCE { certificationPath [0] CertificationPath certificateRevocationList [1] CertificateList OPTIONAL } CertificationPath ::= SEQUENCE { userCertificate [0] SingleCertificate theCACertificates [1] SEQUENCE OF CertificatePair OPTIONAL } -- certif. path from target to source SingleCertificate ::= CHOICE { -- only one for now Certificate -- imported from [X.509] } -- (1993) REQ_TOKEN ::= SIGNED SEQUENCE { timestamp [0] UTCTime -- may be NULL for -- mechanism SPKM-1 randSrc [1] Random_Integer, targ_name [2] INTERNAL NAME, req_data [3] Context_Data, key_estb_id [4] OBJECT IDENTIFIER -- specifies key -- estb. mechanism key_estb_req [5] BIT STRING -- key estb. request } Random_Integer ::= BIT STRING Context_Data ::= SEQUENCE { channelId [0] ChannelId, -- channel bindings seq_number [1] INTEGER OPTIONAL -- sequence number options [2] Options symm_alg [3] Symm_Alg -- symmetric enc. alg. intg_alg [4] Intg_Alg -- integrity algorithm } Adams Document Expiration: 31 December 1994 7 ChannelId ::= OCTET STRING Options ::= BIT STRING { delegation_state (0), mutual_state (1), replay_det_state (2), sequence_state (3), conf_avail (4), integ_avail (5) } Symm_Alg ::= SEQUENCE OF OBJECT IDENTIFIER -- for SEQ_ALG, CONF_ALG Intg_Alg ::= SEQUENCE OF OBJECT IDENTIFIER -- order of agreed -- sequence determines -- meaning of QOP -- parameter A context establishment sequence based on the SPKM will perform one- way authentication (without confirmation or any return token from target to initiator in response to the initiator's SPKM_REQ) if the mutual_req bit is not set in the application's call to gss_init_sec_context(). Applications requiring authentication of both peers (initiator as well as target) should request mutual authentication, resulting in "mutual_state" being set within SPKM_REQ Options. In response to such a request, the context target will reply to the initiator with a token containing either an SPKM_REP_TI or SPKM_ERROR. If mechanism SPKM-2 has been chosen, this completes the 2-way mutual authentication context establishment exchange. If mechanism SPKM-1 has been chosen and SPKM_REP_TI is sent, the initiator will then reply to the target with either an SPKM_REP_IT or SPKM_ERROR, completing the 3-way mutual context establishment exchange. Relevant SPKM_REP_TI syntax is as follows: SPKM_REP_TI ::= SIGNED SEQUENCE { timestamp [0] UTCTime -- may be NULL for -- mechanism SPKM-1 randTarg [1] Random_Integer, src_name [2] INTERNAL NAME, randSrc [3] Random_Integer, rep_data [4] Context_Data, key_estb_rep [5] BIT STRING OPTIONAL -- key estb. response } Adams Document Expiration: 31 December 1994 8 Relevant SPKM_REP_IT syntax is as follows: SPKM_REP_IT ::= SIGNED SEQUENCE { randTarg [0] Random_Integer, targ_name [1] INTERNAL NAME } The syntax of SPKM_ERROR is as follows: SPKM_ERROR ::= [APPLICATION xx] SEQUENCE { pvno[0] INTEGER, msg-type[1] INTEGER, error-code[2] INTEGER, name[3] INTERNAL NAME, e-text[4] GeneralString OPTIONAL, e-data[5] OCTET STRING OPTIONAL } Values to be transferred in the error-code field of a SPKM_ERROR message are defined in Section 5 of this specification. Adams Document Expiration: 31 December 1994 9 3.2. Per-Message and Context Deletion Tokens Three classes of tokens are defined in this section: "Sign" tokens, emitted by calls to gss_sign() and consumed by calls to gss_verify(), "Seal" tokens, emitted by calls to gss_seal() and consumed by calls to gss_unseal(), and context deletion tokens, emitted by calls to gss_delete_sec_context() and consumed by calls to gss_process_context_token(). 3.2.1. Per-message Tokens - Sign Use of the gss_sign() call yields a token, separate from the user data being protected, which can be used to verify the integrity of that data as received. The token has the following format: # of Bytes Name Description 2 TOK_ID Identification field. Tokens emitted by gss_sign() contain the hex value 01 01 in this field. variable INT_ALG Integrity algorithm indicator (must be one of the agreed integrity algorithms for this context). OBJECT IDENTIFIER variable SEQ_ALG Encryption alg. to compute sequence (must be one of the agreed symmetric algorithms for this context). OBJECT IDENTIFIER 2 filler Contains ff ff. 2 INT_LEN Contains bitlength of checksum. 8 SND_SEQ Sequence number field. variable INT_CKSUM Checksum of "to-be-signed data", calculated according to algorithm specified in INT_ALG field. GSS-API tokens must be encapsulated within the higher-level protocol by the application; no embedded length field is necessary. 3.2.1.1. Checksum Checksum calculation procedure (common to all algorithms): Checksums are calculated over the data field, logically prepended by the first 8 bytes of the plaintext packet header. The result binds the data to the packet type and integrity algorithm identifier fields. For example, if the INT_ALG specifies the md5WithRSA algorithm, then the checksum is formed by computing an MD5 [RFC-1321] hash over the plaintext data, and then computing an RSA signature on the 16-byte MD5 result. The signature is computed using the RSA private key retrieved from the credentials structure. The result (of bitlength INT_LEN) is stored in the INT_CKSUM field. Note that for gss_sign(), INT_ALG cannot specify a symmetric encryption algorithm. Adams Document Expiration: 31 December 1994 10 3.2.1.2. Sequence Number Sequence number field: The 8 byte plaintext sequence number field is formed from the sender's four-byte sequence number as follows. If the four bytes of the sender's sequence number are named s0, s1, s2 and s3 (from least to most significant), the plaintext sequence number field is the 8 byte sequence: (s0, s1, s2, s3, di, di, di, di), where 'di' is the direction-indicator (Hex 0 - sender is the context initiator, Hex FF - sender is the context acceptor). The field is then CBC encrypted using the symmetric algorithm specified in SEQ_ALG, the context key, and an IV formed from the first 8 bytes of the previously calculated INT_CKSUM field. After sending a gss_sign() or gss_seal() token, the sender's sequence number is incremented by one. The receiver of the token will first verify the INT_CKSUM field. If valid, the sequence number field may be decrypted and compared to the expected sequence number. The repetition of the (effectively 1-bit) direction indicator within the sequence number field provides redundancy so that the receiver may verify that the decryption succeeded. Since the checksum computation is used as an IV to the sequence number decryption, attempts to splice a checksum and sequence number from different messages will be detected. The direction indicator will detect packets that have been maliciously reflected. 3.2.2. Per-message Tokens - Seal Use of the gss_seal() call yields a token which encapsulates the input user data (optionally encrypted) along with associated integrity check quantities. The token emitted by gss_seal() consists of an integrity header whose format is identical to that emitted by gss_sign() (except that the TOK_ID field contains the value 02 01), followed by a body portion that contains either the plaintext data (if CONF_ALG = ff ff) or encrypted data for any other supported value of CONF_ALG. Adams Document Expiration: 31 December 1994 11 The gss_seal() token has the following format: # of Bytes Name Description 2 TOK_ID Identification field. Tokens emitted by gss_seal() contain the hex value 02 01 in this field. variable INT_ALG Integrity algorithm indicator (must be one of the agreed integrity algorithms for this context). OBJECT IDENTIFIER variable SEQ_ALG Encryption alg. to compute sequence (must be one of the agreed symmetric algorithms for this context). OBJECT IDENTIFIER variable CONF_ALG Confidentiality algorithm indicator (must be 'ff ff' or one of the agreed symmetric algorithms for this context). OBJECT IDENTIFIER ff ff - none 2 INT_LEN Contains bitlength of checksum. 8 SND_SEQ Encrypted sequence number field. variable INT_CKSUM Checksum of plaintext padded data, calculated according to algorithm specified in INT_ALG field. variable Data encrypted or plaintext padded data GSS-API tokens must be encapsulated within the higher-level protocol by the application; no embedded length field is necessary. 3.2.2.1. Checksum Checksum calculation procedure (common to all algorithms): Checksums are calculated over the plaintext padded data field, logically prepended by the first 8 bytes of the plaintext packet header. The result binds the data to the packet type, protocol version, and integrity algorithm identifier fields. For example, if the INT_ALG specifies the md5WithRSA algorithm, then the checksum is formed by computing an MD5 [RFC-1321] hash over the plaintext data, and then computing an RSA signature on the 16-byte MD5 result. The signature is computed using the RSA private key retrieved from the credentials structure. The result (of bitlength INT_LEN) is stored in the INT_CKSUM field. As another example, if the INT_ALG specifies a symmetric encryption algorithm such as the DES-CBC algorithm -- note that this is allowable for gss_seal() but not for gss_sign() -- then the encrypted data itself acts as the checksum (therefore CONF_ALG must be the same as INT_ALG). In this case the INT_CKSUM field contains the last eight bytes of the encrypted data and INT_LEN contains the value 64. Adams Document Expiration: 31 December 1994 12 3.2.2.2 Sequence Number Sequence number field: The 8 byte plaintext sequence number field is formed from the sender's four-byte sequence number as follows. If the four bytes of the sender's sequence number are named s0, s1, s2 and s3 (from least to most significant), the plaintext sequence number field is the 8 byte sequence: (s0, s1, s2, s3, di, di, di, di), where 'di' is the direction-indicator (Hex 0 - sender is the context initiator, Hex FF - sender is the context acceptor). The field is then CBC encrypted using the symmetric algorithm specified in SEQ_ALG, the context key, and an IV formed from the first 8 bytes of the INT_CKSUM field. After sending a gss_sign() or gss_seal() token, the sender's sequence numbers are incremented by one. 3.2.2.3: Padding Data padding: Before encryption and/or integrity checksum calculation, plaintext data is padded to the next highest multiple of 8 bytes, by appending between 1 and 8 bytes, the value of each such byte being the total number of pad bytes. For example, given data of length 20 bytes, four pad bytes will be appended, and each byte will contain the hex value 04. An 8-byte random confounder is prepended to the data, and integrity checksums are calculated over the resulting padded plaintext. After padding, the data is encrypted according to the algorithm specified in the CONF_ALG field. The data is encrypted using CBC with an IV of zero. The key used is derived from the established context key by XOR-ing the context key with the hexadecimal constant f0f0f0f0f0f0f0f0. Adams Document Expiration: 31 December 1994 13 3.2.3. Context deletion token The token emitted by gss_delete_sec_context() is based on the packet format for tokens emitted by gss_sign(). The context-deletion token has the following format: # of Bytes Name Description 2 TOK_ID Identification field. Tokens emitted by gss_delete_sec_context() contain the hex value 01 02 in this field. variable INT_ALG Integrity algorithm indicator (must be one of the agreed integrity algorithms for this context). OBJECT IDENTIFIER variable SEQ_ALG Encryption alg. to compute sequence (must be one of the agreed symmetric algorithms for this context). OBJECT IDENTIFIER 2 filler Contains ff ff. 2 INT_LEN Contains bitlength of checksum. 8 SND_SEQ Sequence number field. variable INT_CKSUM Checksum of "to-be-signed data", calculated according to algorithm specified in INT_ALG field. SND_SEQ will be calculated as for tokens emitted by gss_sign(). The INT_CKSUM will be calculated as for tokens emitted by gss_sign(), except that the user-data component of the "to-be-signed" data will be a zero-length string. Adams Document Expiration: 31 December 1994 14 4. NAME TYPES AND OBJECT IDENTIFIERS No name types have yet been defined for SPKM. This section is for further study. 5. PARAMETER DEFINITIONS This section defines parameter values used by the SPKM GSS-API mechanism. It defines interface elements in support of portability. 5.1. Minor Status Codes This section recommends common symbolic names for minor_status values to be returned by the SPKM GSS-API mechanism. Use of these definitions will enable independent implementors to enhance application portability across different implementations of the mechanism defined in this specification. (In all cases, implementations of gss_display_status() will enable callers to convert minor_status indicators to text representations.) Each implementation should make available, through include files or other means, a facility to translate these symbolic names into the concrete values which a particular GSS-API implementation uses to represent the minor_status values specified in this section. It is recognized that this list may grow over time, and that the need for additional minor_status codes specific to particular implementations may arise. 5.1.1. Non-SPKM-specific codes (Note that other codes may be added in the future.) GSS_S_G_NOUSER /* "UID does not resolve to username" */ GSS_S_G_VALIDATE_FAILED /* "Validation error" */ GSS_S_G_BUFFER_ALLOC /* "Couldn't allocate gss_buffer_t data" */ GSS_S_G_BAD_MSG_CTX /* "Message context invalid" */ GSS_S_G_WRONG_SIZE /* "Buffer is the wrong size" */ GSS_S_G_BAD_USAGE /* "Credential usage type is unknown" */ GSS_S_G_UNAVAIL_QOP /* "Unavailable quality of protection specified" */ Adams Document Expiration: 31 December 1994 15 5.1.2. SPKM-specific-codes (Note that other codes may be added in the future.) GSS_SPKM_S_KG_CCACHE_NOMATCH /* "Principal in credential cache does not match desired name" */ GSS_SPKM_S_KG_CONTEXT_ESTABLISHED /* "Context is already fully established" */ GSS_SPKM_S_KG_BAD_INT_ALG_TYPE /* "Unknown integrity algorithm type in token" */ GSS_SPKM_S_KG_BAD_LENGTH /* "Invalid field length in token" */ GSS_SPKM_S_KG_CTX_INCOMPLETE /* "Attempt to use incomplete security context" */ 5.2. Quality of Protection Values Quality of Protection (QOP) values are defined for the SPKM GSS-API mechanism, and are used as input to gss_sign() and gss_seal() to select among alternate integrity-checking algorithms. Once a set of algorithms has been agreed upon by the context initiator and target, the QOP parameter simply selects from this ordered set. More specifically, the SPKM_REQ token may send a sequence of "n" OBJ. IDs specifying integrity-checking algorithms supported by the initiator. The target may support only a subset m (m <= n) of these, and so will return the sequence of "m" OBJ. IDs which it supports in the SPKM_REP_TI token. The first OBJ. ID is therefore the default algorithm (QOP = 0), and the next m-1 are used for QOP = 1 through QOP = m-1, respectively. Any QOP value greater than or equal to m is equated to m-1 and is therefore mapped to the last OBJ. ID in the agreed set. To aid in implementation and interoperability, the following stipulations are made. The set of n OBJ. IDs sent by the initiator must contain at least one specifying an algorithm which computes a true digital signature, must contain at least one specifying any other (non-signature) integrity algorithm, and may contain at least one specifying a symmetric algorithm. The set of m OBJ. IDs returned by the target must contain one specifying an algorithm which computes a true digital signature in the first position, must contain one specifying a (non-signature) integrity algorithm in the second position, and must contain one specifying a symmetric encryption algorithm or NULL in the final position. Adams Document Expiration: 31 December 1994 16 The reason for these stipulations is to allow the QOP parameter to convey the semantics of the desired integrity service without forcing it to specify the actual algorithms to be used. The result is that the application is always able to choose, in a completely general and portable way, an integrity service which provides non-repudiation semantics (by passing QOP = Hex 00), one which does not provide non- repudiation semantics (by passing QOP = Hex 01), and one which uses encryption for both integrity and confidentiality -- if this is available over the established context -- (by passing QOP = Hex FF). Note that an application which is aware of its own underlying environment and/or is aware of the underlying environment of its peer is not unduly constrained by the above stipulations because any other number or kind of algorithms may be agreed upon during context establishment, making other QOP values perfectly valid and meaningful over that context and between those peers. 6. SECURITY CONSIDERATIONS Security issues are discussed throughout this memo. 7. REFERENCES [RFC-1321]: R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321. [RFC-1422]: S. Kent, "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", RFC 1422. [RFC-1507]: C. Kaufman, "DASS: Distributed Authentication Security Service", RFC 1507. [RFC-1508]: J. Linn, "Generic Security Service Application Program Interface", RFC 1508. [RFC-1509]: J. Wray, "Generic Security Service Application Program Interface: C-bindings", RFC 1509. [RFC-1510]: J. Kohl and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510. [KRB5]: J. Linn, "The Kerberos Version 5 GSS-API Mechanism", Internet Draft draft-ietf-cat-kerb5gss-00. [FIPS-113]: National Bureau of Standards, Federal Information Processing Standard 113, "Computer Data Authentication", May 1985. [PKCS]: RSA Encryption Standard, Version 1.4, RSA Data Security, Inc., June 3, 1991. [X.509]: ISO/IEC 9594-8, "Information Technology - Open Systems Interconnection - The Directory: Authentication Framework", CCITT Recommendation X.509. [X9.44]: ANSI, "Public Key Cryptography Using Reversible Algorithms for the Financial Services Industry: Transport of Symmetric Algorithm Keys Using RSA", X9.44-1993. Adams Document Expiration: 31 December 1994 17 8. AUTHOR'S ADDRESS Carlisle Adams Bell-Northern Research, Ltd. P.O.Box 3511, Station C Ottawa, Ontario, CANADA K1Y 4H7 Phone: +1 613.763.9008 E-mail: cadams@bnr.ca Adams Document Expiration: 31 December 1994 18 Appendix: IMPORTS A.1 ASN.1 encoding The following definitions are taken from X.501 and X.509. --CCITT Definitions: joint-iso-ccitt OBJECT IDENTIFIER ::= {2} ds OBJECT IDENTIFIER ::= {joint-iso-ccitt 5} algorithm OBJECT IDENTIFIER ::= {ds 8} encryptionAlgorithm OBJECT IDENTIFIER ::= {algorithm 1} hashAlgorithm OBJECT IDENTIFIER ::= {algorithm 2} signatureAlgorithm OBJECT IDENTIFIER ::= {algorithm 3} rsa OBJECT IDENTIFIER ::= {encryptionAlgorithm 1} iso OBJECT IDENTIFIER ::= {1} identified-organization OBJECT IDENTIFIER ::= {iso 3} --1989 OSI Implementors Workshop "Stable" Agreements oiw OBJECT IDENTIFIER ::= {identified-organization 14} dssig OBJECT IDENTIFIER ::= {oiw 7} oiwAlgorithm OBJECT IDENTIFIER ::= {dssig 2} oiwEncryptionAlgorithm OBJECT IDENTIFIER ::= {oiwAlgorithm 1} oiwHashAlgorithm OBJECT IDENTIFIER ::= {oiwAlgorithm 2} oiwSignatureAlgorithm OBJECT IDENTIFIER ::= {oiwAlgorithm 3} --PKCS #1 definition [PKCS] rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } --X.501 definitions AttributeType ::= OBJECT IDENTIFIER AttributeValue ::= ANY AttributeValueAssertion ::= SEQUENCE {AttributeType,AttributeValue} Name ::= CHOICE { --only one for now RDNSequence } RDNSequence ::= SEQUENCE OF RelativeDistinguishedName DistinguishedName ::= RDNSequence RelativeDistinguishedName ::= SET OF AttributeValueAssertion Adams Document Expiration: 31 December 1994 19 --X.509 definitions (with proposed 1992 extensions presumed) ENCRYPTED MACRO ::= BEGIN TYPE NOTATION ::= type(ToBeEnciphered) VALUE NOTATION ::= value(VALUE BIT STRING) END -- of ENCRYPTED SIGNED MACRO ::= BEGIN TYPE NOTATION ::= type (ToBeSigned) VALUE NOTATION ::= value (VALUE SEQUENCE{ ToBeSigned, AlgorithmIdentifier, --of the algorithm used to --generate the signature ENCRYPTED OCTET STRING --where the octet string is the --result of the hashing of the --value of "ToBeSigned" } ) END -- of SIGNED SIGNATURE MACRO ::= BEGIN TYPE NOTATION ::= type (OfSignature) VALUE NOTATION ::= value (VALUE SEQUENCE { AlgorithmIdentifier, --of the algorithm used to compute ENCRYPTED OCTET STRING -- the signature where the octet -- string is a function (e.g., a -- compressed or hashed version) -- of the value 'OfSignature', -- which may include the -- identifier of the algorithm -- used to compute the signature } ) END -- of SIGNATURE Certificate ::= SIGNED SEQUENCE { version [0] Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUID [1] IMPLICIT UID OPTIONAL, -- used in v2 only subjectUID [2] IMPLICIT UID OPTIONAL -- used in v2 only } Adams Document Expiration: 31 December 1994 20 Version ::= INTEGER {v1(0), v2(1)} CertificateSerialNumber ::= INTEGER Validity ::= SEQUENCE { NotBefore UTCTime, NotAfter UTCTime } AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameter ANY DEFINED BY algorithm OPTIONAL } SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING } UID ::= BIT STRING CertificatePair ::= SEQUENCE { forward [0] SingleCertificate OPTIONAL, reverse [1] SingleCertificate OPTIONAL } -- at least one of the pair shall be present CertificateList ::= SIGNED SEQUENCE { signature [0] AlgorithmIdentifier, issuer [1] Name, thisUpdate [2] UTCTime, nextUpdate [3] UTCTime OPTIONAL, revokedCertificates SEQUENCE OF SEQUENCE { userCertificate CertificateSerialNumber, revocationDate UTCTime } OPTIONAL } Adams Document Expiration: 31 December 1994 21 A.2 Encoding Rules Whenever a structure is to be signed it must always be constructed the same way. This is particularly important where a signed structure has to be reconstructed by the recipient before the signature is verified. The rules listed below are taken from X.509. - the definite form of length encoding shall be used, encoded in the minimum number of octets; - for string types, the constructed form of encoding shall not be used; - if the value of a type is its default value, it shall be absent; - the components of a Set type shall be encoded in ascending order of their tag value; - the components of a Set-of type shall be encoded in ascending order of their octet value; - if the value of a Boolean type is true, the encoding shall have its contents octet set to `FF'16; - each unused bits in the final octet of the encoding of a BitString value, if there are any, shall be set to zero; - the encoding of a Real type shall be such that bases 8, 10 and 16 shall not be used, and the binary scaling factor shall be zero. Adams Document Expiration: 31 December 1994 22