Network Working Group W. Doonan Internet Draft Surety Technologies Expires April 20, 2000 SPKM with Shared Secret Keys (SSKM) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document presents a method for using [SPKM] with exclusively shared secret key technologies. The messages and tokens of [SPKM] are unchanged; the only modifications required are to replace the default public-key cipher suite with ciphers and algorithms suitable for use with shared secret keys. All messages and tokens defined in [SPKM] are preserved; no changes are required to the various authentication modes of [SPKM]. Integrity algorithms and key establishment algorithms suitable for use with secret keys are added to those specified in [SPKM], which are well known and specified for use in other existing IETF standards. We in effect implement the implicit authenticated key exchange protocol proposed in [BR94] using the messages and tokens defined in [SPKM]. An overview and brief discussion of the protocol appears in section 1. The specific algorithms and object identifiers are listed in section 2. Discussion of how [SPKM] messages are used with shared secret keys appears in section 3. Security concerns are addressed in section 4. Patent issues are covered in section 5. 1. Overview Page 1 The purpose of [GSS2] is to define and extensible framework for establishing a security context between peers for use in securing communications between those peers. In turn, [SPKM] provides the means for peers to use digital certificates for both authentication and for computing session keys. The token formats and messages defined in [SPKM] are used without modification, but employ only shared secret key technologies for authentication and computation of session keys. The rationale is to provide a bridge between existing secret key (username/password or token-based) infrastructures and more scalable infrastructures based on digital signatures and certificates. Well-known algorithms such as [DES] and [HMAC] are used, which have also been extensively analyzed, and in fact are required by recently- adpoted standards such as [IKE]. By using both existing algorithms and a protocol with a strong existing proof of security, we avoid introducing new cryptographic transforms or protocols requiring extensive new analysis. 1.1 Two-Party Authenticated Key Exchange The authentication and key establishment algorithms presented here have been extensively analyzed by Mihir Bellare and Phillip Rogaway in [BR94]. In this paper the authors prove the security of a series of two-party, shared secret key authentication and key exchange protocols against a strong threat model. The protocol variant implemented here is referred to in the paper as AKEP2. The protocol conversation is summarized below: A. The initiator generates a random number and sends it to the target. B. The target generates another random number and sends both random numbers back to the initiator, along with an integrity value computed using both random values and a shared secret key. C. The initiator uses both random values and the shared secret key to compute the expected integrity value. If the integrity value sent by the target matches the computed integrity value, the target is authenticated. D. The initiator sends the target's random value back to the target, along with an integrity value computed using the target's random value and the shared secret key. E. The target uses the random value and the shared secret key to compute the expected integrity value. If the integrity value sent by the initiator matches the computed integrity value, the initiator is authenticated. F. Both initiator and target compute a session key by passing the target's random value through a strong pseudorandom permutation Page 2 function. The strong pseudorandom permutation function is seeded with the shared secret key. The key exchange algorithm is referred to as "implicit" because the eventual session key is computed using the random values exchanged during mutual authentication. Steps A through E are essentially identical to the SPKM-1 operating mode when used with mutual authentication, hence [SPKM] can be used to implement this portion of AKEP2 directly. Step F is essentially a new key establishment algorithm, and hence can be chosen as the desired K-ALG during initial algorithm negotiation. The key establishment algorithm in step F is based on using a strong pseudorandom permutation function, rather than a simple pseudorandom number generator. [BR94] identifies [DES] as a good candidate for such a function, hence the key establishment algorithm specified here is [DES]. Use of [DES] in this manner is prone to confusion, as [DES] is normally used as a confidentiality algorithm, and is also under fire as being relatively insecure for confidentiality purposes. However, [DES] is only being here used for it's pseudorandom permutation properties, and only for computing a session key, rather than as a means for encrypting actual data traffic. In addition, [BR94] only requires that the key establishment algorithm exhibit strong pseudorandom permutation properties; thus if [DES] is considered unsuitable for use even in this capacity it can be replaced with other functions with better or stronger permutation properties. 2. Algorithms, Name Types, and Object Identifiers As mentioned above, no changes to the token formats or messages defined in [SPKM] are required to operate with shared secrey keys, and all existing operating modes are preserved. The only changes to [SPKM] required to operate exclusively with shared secret keys is to augment the choice of integrity and key establishment algorithms. 2.1 Integrity Algorithm (I-ALG) The MANDATORY message integrity algorithm specified in [SPKM] is md5WithRSAEncryption. To use [SPKM] with shared secret keys, additional integrity algorithms are needed. When operating this way we allow the I-ALG to be any of the [HMAC] transforms currently defined for use in [IKE]. Examples: HMAC-MD5 OBJECT IDENTIFIER ::= { iso(1) org(3) dod(6) internet(1) security(5) mechanisms(5) ipsec(8) isakmpOakley(1) HMAC-MD5(1) } Page 3 HMAC-SHA OBJECT IDENTIFIER ::= { iso(1) org(3) dod(6) internet(1) security(5) mechanisms(5) ipsec(8) isakmpOakley(1) HMAC-SHA(2) } HMAC-TIGER OBJECT IDENTIFIER ::= { iso(1) org(3) dod(6) internet(1) security(5) mechanisms(5) ipsec(8) isakmpOakley(1) HMAC-TIGER(3) } HMAC-RIPEMD160 OBJECT IDENTIFIER ::= { iso(1) org(3) dod(6) internet(1) security(5) mechanisms(5) ipsec(8) isakmpOakley(1) HMAC-RIPEMD160(4) } To ensure interoperability, HMAC-SHA is the MANDATORY integrity algorithm. 2.2 Confidentiality Algorithm (C-ALG) Using [SPKM] with shared secret keys does not require changes to the set of available confidentiality algorithms. 2.3 Key Establishment Algorithm (K-ALG) The MANDATORY algorithm for key establishment specified in [SPKM] is RSAEncryption. To operate exclusively with shared secret keys, the session key is computed by randomizing the exchanged random key material with a suitable strong pseudorandom permutation function. The [DES] algorithm is one such algorithm, and is in fact recommended by [BR94]. DES-CBC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 7 } The key establishment algorithm is applied to the random value generated by the target, as in section 1.1.F. 2.4 One-Way Function for Subkey Derivation (O-ALG) Using [SPKM] with shared secret keys does not require changes to the set of available one-way functions for subkey derivation. 2.5 Name Types When using [SPKM] exclusively with shared secret keys, there are no certificates present and hence various required name fields must be Page 4 obtained and expressed in some alternate form. We thus express names using the name forms and object identifiers defined in [GSS2]. gss-host-based-services OBJECT IDENTIFIER ::= { iso(1) org(3) dod(6) internet(1) security(5) nametypes(6) gss-host-based-services(2) } user-name OBJECT IDENTIFIER ::= { iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) generic(1) user_name(1) } 3. Using SPKM with shared secret keys When using [SPKM] with shared secret keys, the purpose of the initial message exchange is to both authenticate the parties to the exchange and to agree upon some randomly-generated key material. The protocol presented in [BR94] can be expressed directly through use of SPKM-1 with mutual authentication enabled. However, the additional message exchanges (SPKM-2) and authentication modes (unilateral) supported by [SPKM] can also be used when operating with shared secret keys. All authentication exchanges and modes eventually allow the peers to reliably exchange some random key material. The random key material is used to compute a session key according to the method detailed in section 1.1.F. The session key is computed by encrypting the random key material with [DES], in this case using a subkey derived from the shared secret key according to the agreed upon one-way function and key derivation algorithm. The computed session key is then used to derive all other subkeys according to normal [SPKM] practices. 3.1 SPKM-REQ message When using [SPKM] with shared secret keys, various optional fields in the message are always absent. The "certif-data", "auth-data", "validity", and "key-src-bind" fields are all absent, and the "options" field of the "Context-Data" structure cannot have the "target-certif-data-required" bit set. The "key-estb-req" field is also empty, except for unilateral authentication of initiator to target using SPKM-2. In this case the "key-estb-req" field contains the random key material to be used in computing the session key. The "src-name" field MUST contain a name indicating the identity of the initiator, so that the target can find the secret key it shares with the initiator. For example, in applications with existing username/password infrastructures, the "src-name" would be a username encoded in the user-name name form. All other fields are filled with values appropriate for the current [SPKM] operating mode. The "req-integrity" field is formed by computing any of the supported Page 5 [HMAC] transforms on the "req-contents" field, as with other I-ALGs. The key used by the [HMAC] transform to compute the integrity value is derived from the shared secret key according to the key derivation algorithm defined in Section 2.4 of [SPKM]. The "owf-alg" field of the "Context-Data" structure MUST have as its first element the OID of the one-way function used by the subkey derivation algorithm to compute the key used in the [HMAC] transform. 3.2 SPKM-REP-TI message When using [SPKM] with shared secret keys, the optional "certif-data" and "validity" fields are always absent. The "key-estb-str" field contains the random key material used to compute the session key. All other fields are filled with values appropriate to the current [SPKM] operating mode. The "rep-ti-integ" field is formed in the same manner as the "req-integrity" field is formed in section 3.1. The protocol presented in [BR94] and summarized in section 1.1 uses a single random number generated by the target to both authenticate the initiator and target, and for computing the session key. When implemented using [SPKM], we use the "randTarg" value to authenticate the parties, and the "key-estb-str" value as the value from which we compute the session key. Separating the values does not violate the security of the protocol, as both fields are part of the integrity computation. Separating them allows the random values used to authenticate the parties to be fixed length, while allowing the key material exchanged for use in computing session keys to vary in length, to suit the needs of the integrity and confidentiality algorithms negotiated by the parties. Separating the values also follows good cryptographic practice of using a single entity for a single purpose. 3.3 SPKM-REP-IT message The "key-estb-rep" field is always absent, while all other fields are filled with values appropriate to the current [SPKM] operating mode. The "rep-it-integ" field is formed in the same manner as the "req- integrity" field is formed in section 3.1. 3.4 SPKM-ERROR message All fields are filled with values appropriate to the current [SPKM] operating modes. The "integrity" field is formed in the same manner as the "req-integrity" field is formed in section 3.1. 3.5 Other messages Once the initial authentication and key establishment messages have Page 6 been exchanged, all SPKM-MIC, SPKM-WRAP, and SPKM-DEL messages are unchanged. 4. Security Considerations The authentication and key establishment algorithms presented here were proven secure in [BR94] according to the realistic threat model also presented in that paper. The theorems and proofs are presented in the paper and are outside the scope of this document. The paper makes certain cryptographic requirements on various primitives used in constructing the protocol, however. 4.1 Random values The protocols presented in [BR94] require that the random challenges be "unpredictable", in the cryptographic sense, rather than simple nonces. The [SPKM] specification, however, requires only that the random challenges be "fresh". Hence, using [SPKM] with shared secret keys imposes additional requirements on the process used to generate the random challenges. While it is impossible to generate "unpredictable" random values algorithmically, one can use software functions that gather entropy to generate "unpredictable" values of reasonable quality. An example of an entropy-based random number generator can be found in the CryptoLib software package, written by Matt Blaze et.al. at AT&T Labs. This package includes a "truerand" function which uses the variability of the number of times a simple calculation can occur within a fixed amount of clock time on common timesharing operating systems. This approach works well compared to other entropy gathering algorithms that capture mouse clicks and keyboard events, and which thus require user interaction. 4.2 Shared secret keys As with any cryptosystem, the security of this system is directly related to the strength of the keys in use. The shared secret keys used here should conform to the usual and well-known criteria for selecting strong keys. 4.3 Session key computation A strong pseudorandom permutation function is required in order to compute the negotiated session key. [BR94] suggests that the [DES] algorithm, while under strong attack as an encryption algorithm, is suitable for use as a strong pseudorandom permutation function. Rather than invent a new generator, then, we choose to follow this recommendation and use [DES] to compute session keys. Page 7 4.4 Message integrity The message integrity functions used in [BR94] are based on strong pseudorandom generators, such as DES-MAC or md5-DES-CBC. The paper also lists pure hash functions as possible candidates, but warns that their security characteristics in this application are less well justified. However, in the time since [BR94] was initially published the authors have developed and analyzed the [HMAC] constructions, which in turn have been deemed suitably strong for use in other IETF standards. Hence we add them to the list of recommended integrity algorithms for [SPKM]. 4.5 Initial subkey derivation Two keys are needed during initial message exchange, one to compute integrity values on the messages and one to compute the eventual session key. [BR94] uses the same shared secret key both for computing integrity values and for computing the session key. To avoid concerns about using a single cryptographic object for two different purposes, the two keys used during initial message exchange are derived from the single shared secret using the key derivation algorithm specified in Section 2.4 of [SPKM]. An integrity subkey is derived from the single shared secret and used to compute the [HMAC] integrity values on all initial messages. Likewise a confidentiality subkey is derived from the single shared secret and is used to compute the negotiated session key. The one-way function used to derive these initial subkeys is indicated in the "owf-alg" field of the "Context-Data" element included in the initial message exchange. 5. Intellectual Property Rights The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to per- tain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Page 8 6. References [GSS2] J. Linn, "Generic Security Service Application Program Interface, Version 2," RFC 2078, January 1997. [SPKM] C. Adams, "The Simple Public-Key GSS-API Mechanism (SPKM)," RFC 2025, October 1996. [BR94] M. Bellare, P. Rogaway, "Entity Authentication and Key Distribution," Extended abstract in Advances in Cryptology - Crypto 93 Proceedings, Lecture Notes in Computer Science Vol. 773, D. Stinson ed, Springer-Verlag, 1994. [DES] ANSI X3.106, "American National Standard for Information Systems-Data Link Encryption," American National Standards Institute, 1983. [HMAC] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for Message Authentication," RFC 2104, February 1997. [IKE] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)," RFC 2409, November 1998. 7. Authors' Addresses Address comments related to this submission to: cat-ietf@mit.edu Wes Doonan Surety Technologies Inc. 1890 Preston White Drive Reston, VA 20191 wes@surety.com Expires April 20, 2000 Page 9