Internet Draft R. Moskowitz Document: draft-moskowitz-shared-secret- ICSAlabs provprotocol-00.txt Expires: June 2003 December 2002 Shared Secret Provisioning Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 Shared secrets are common in IETF protocols. Setting these shared secrets is typically defined as out of scope of those protocols. The upshot of this approach is poor security practices in setting these secrets and, through the life of the implementation, changing these secrets. The Shared Secret Provisioning Protocol (SSPP) provides a mechanism for both setting and changing shared secrets that are provably strong. Conventions used in this document In examples, "C:" and "S:" indicate activities by the client and server respectively. Moskowitz Expires - June 2003 [Page 1] Shared Secret Provisioning Protocol December 2002 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Table of Contents 1. Introduction...................................................2 1.1 Diffie-Hellman and Man-in-the-Middle Attacks...............2 2. The Diffie-Hellman Key Agreement Schemes.......................3 2.1 The Fixed Field Diffie-Hellman exchange....................3 2.2 The Elliptic Curve Diffie-Hellman exchange.................3 2.3 The Key Derivation Function................................4 3. The Shared Secret Provisioning Protocol........................5 3.1 Managing Risk in SSPP......................................6 Security Considerations...........................................6 References........................................................7 Acknowledgments...................................................7 Author's Addresses................................................7 1. Introduction Provisioning strong, shared secrets is frequently considered as 'out-of-scope' in most protocols that use them. Yet, the quality of shared secrets has a significant impact on the security characteristics of these protocols. Many of the attacks are specifically related to the prevalent use of weak shared secrets. This calls out for a standard protocol to provisioning strong shared secrets that can be implemented over case-specific transports. The Shared Secret Provisioning Protocol (SSPP) provides a mechanism for both setting and changing shared secrets that are provably strong. It is based on the well-known properties of a Diffie- Hellman Key Agreement. Both Fixed Field and Elliptic Curve forms are available. The key derivation methodology is derived from the NIST Key Management Schemes proposal [3] which drew heavily on X9.42 and x9.63. This is a basic exchange; the actual implementation is left to specific cases. Although SSPP is based on static Diffie-Hellman keys, the use of nonces permit it to be rerun whenever a new shared secret is needed without changing a Diffie-Hellman key. 1.1 Diffie-Hellman and Man-in-the-Middle Attacks Although Diffie-Hellman is commonly used for establishing a secret between two parties, typically buried within a complex protocol like Moskowitz Expires - April 2003 [Page 2] Shared Secret Provisioning Protocol December 2002 IKE [4], Diffie-Hellman by itself has a significant man-in-the-middle attack. The method used to detect this attack is to validate the public Diffie-Hellman keys that they really came for the expected party. This attack is symmetric. That is really only one party needs to validate the otherÆs public key and back off on the exchange if the validation fails. This symmetric property is important as it allows SSPP to be used in headless devices that cannot easily validate the public key of the other party. 2. The Diffie-Hellman Key Agreement Schemes There are many variants defined for Diffie-Hellman Key Agreement Schemes. They vary first in how many static and ephemeral key pairs and if the math is Fixed Field or Elliptic Curve. Then they vary in if the derived Diffie-Hellman secret is used directly or if it is an input to a keyed hash that produces the actual shared secret. SSPP uses 2 static and no ephemeral Diffie-Hellman key pairs. Both Fixed Field and Elliptic Curve methods are allowed. The key produce from the Diffie-Hellman exchange is inputted into an HMAC-SHA1 [5] keyed hash along with identities for each party and a large, random nonce from each party. 2.1 The Fixed Field Diffie-Hellman exchange Each party has a static key pair (X, Y) that was previously generated using the same domain parameters (p, q, g). Party C has (Xc, Yc); party S has (Xs, Ys). Each party must obtain the other partyÆs static public key. One must obtain the other's in a trusted manner. Each party computes the shared secret Zs as shown below, and then computes the shared secret by invoking the key derivation function using Zs. Party C Party S Input (p, q, g), Xc, Ys (p, q, g), Xs, Yc Computation Zs = Ys^Xc mod p Zs = Yc^Xs mod p 2.2 The Elliptic Curve Diffie-Hellman exchange Moskowitz Expires - April 2003 [Page 3] Shared Secret Provisioning Protocol December 2002 Each party has a static key pair (ds, Qs) that was previously generated using the same domain parameters (q, FR, a, b, [SEED], G, n, h). Party C has (dsC, QsC); party S has (dsS, QsS). Each party must obtain the other partyÆs static public key. One must obtain the other's in a trusted manner. Each party computes the shared secret Zs as shown below, and then computes the shared secret by invoking the key derivation function using Zs. Party C Party S Input (q, FR, a, b, [SEED], (q, FR, a, b, [SEED], G, n, h), dsC,QsS G, n, h), dsS,QsC Computation (Xs, Ys) = hdsCQsS (Xs, Ys) = hdsSQsC Zs = Xs Zs = Xs 2.3 The Key Derivation Function The key derivation function is used to shared secret from Zs as follows: Function call: kdf(Zs, C, S, keydatalen, hashlen, NonceC, NonceS) Input description: 1. A bit string Zs is defined above. 2. Bit strings C and S that denote the identities of the participating parties, where C is the party that initiated the key establishment process, and S is the responder in the key establishment process. 3. An integer keydatalen that is the length in bits of the shared secret to be generated. keydatalen must be less than hashlen x (2^32-1). 4. An integer hashlen that is the length in bits of the hash function to be used to derive the shared secret. Thus the selection of SHA-1, 256, or 512 is determined by the size of the desired shared secret. 5. Bit strings NonceC and NonceS are nonces from the parties C and S respectively. The recommended size for the nonces is twice hashlen. Moskowitz Expires - April 2003 [Page 4] Shared Secret Provisioning Protocol December 2002 Process: a. Initiate a 32-bit, big-endian bit string counter as x00000001. b. For i=1 to i= int(keydatalen/hashlen), do the following: Compute Hashi = HMAC-SHAn(Zs,(counter || min(C,S) || max(C,S) || keydatalen || hashlen || min(NonceC,NonceS) || max(NonceC,NonceS))) Increment counter Increment i. c. Let Hhashj denote Hashj if keydatalen/hashlen is an integer, and let it denote the (keydatalen - (hashlen x (j-1))) leftmost bits of Hashj otherwise. d. Set sharedsecret = Hash1 || Hash2 ||...|| Hashj-1 || Hhashj. Any attempt to call the key derivation function for a shared secret of length greater than or equal to hashlen x (2^32-1) bits must output "invalid" and stop. 3. The Shared Secret Provisioning Protocol In SSPP, the client is the party that starts the exchange and is capable of validating the other partyÆs public key. This may well NOT be the client in the normal sense. For example, if SSPP is used to set a shared secret between a headless monitoring device and a data collection server, the server may be the SSPP client, as it may have a UI to check the fingerprint of the headless device's public key. The basic protocol is: C: REQUEST values from Server S: Generate NonceS SEND (Domain parameters, Public key, AddressS, NonceS) C: If Domain parameters do not match Client's, stop If the Public key is not valid, stop Generate NonceC Generate Shared Secret SEND (Public key, AddressC, NonceC), LTRUN96(HMAC-SHA1(Shared Secret, (Public key || AddressC || NonceC))) S: Generate Shared Secret SEND LTRUNC96(HMAC-SHA1(Shared Secret, (AddressS || NonceS))) Moskowitz Expires - April 2003 [Page 5] Shared Secret Provisioning Protocol December 2002 3.1 Managing Risk in SSPP There are many potential opportunities for attacks against SSPP unless limits are placed on its usage as a PROVISIONING protocol. An SSPP implementation MUST have controls placed on servers as to when they are available to limit attacks against them. A server has no control over which clients provision secrets with them. A resource limited headless device could be rendered useless through this way. It is best if SSPP is only available at device setup time or when triggered through a process authenticated with an existing established shared secret. Since for the server, it is possible to attack the nonce state, the server implementation could use the same nonce until an SSPP exchange is completed, and only then select a new nonce for the next SSPP request. The client needs some method of validating the serverÆs public key. This can be through a check of the fingerprint (hash) of the public key, where the fingerprint was obtained in some out-of-band process. Or the physical network between the client and server might be such that no man-in-the-middle is possible (for example with a crossover cable in a deployment staging area). Any instantiation of SSPP needs to examine how an attack might occur and mitigate those attacks. Security Considerations This protocol uses an un-authenticated Diffie-Hellman exchange. This is open to a Man-in-the-Middle attack. The recommended practice for this is that there MUST be a mechanism for the client to validate the serverÆs Diffie-Hellman public key, or for a risk- appropriate assurance that there is no man in the middle between the client and server. The former can be addressed by client system presenting in its UI the fingerprint of the public key. The operator would check the fingerprint with a copy obtained out-of-band (for example stamped on the server). The later can be addressed by connecting the client and server with a crossover cable or by trusting the deployed cabling (as in a small office). The server is potentially open to establishing a shared secret with any system. Since the SSPP server is typically a client for all other services, this could leave it open to attack through the services that the shared secret is suppose to protect. As such, there must be an external control on the use of SSPP for the Moskowitz Expires - April 2003 [Page 6] Shared Secret Provisioning Protocol December 2002 servers. For example, a device might only be an SSPP server when in factory default state or when put into it via some protocol authenticated with an existing shared secret. The size of the Diffie-Hellman keys and the size of the SHA hash determine the strength of the shared secret. It is up to each application of SSPP to select these values, based on the needed shared secret strength. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 NIST, "Key Establishment Schemes Workshop Document", November 2001. http://csrc.nist.gov/encryption/kms/schemes_workshop_doc.pdf 4 Harkins, D., and Carrel, D., "The Internet Key Exchange", RFC 2409, November 1998. 5 Krawczyk, H., and Bellare, R., "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997 Acknowledgments This document is the result of the first IETF Credential provisioning workshop and extracted from the original RADIUS Client Kickstart Internet Draft. Author's Addresses Robert Moskowitz TruSecure/ICSAlabs 1000 Bent Creek Blvd, Suite 200 Mechanicsburg, PA Email: rgm@trusecure.com Moskowitz Expires - April 2003 [Page 7]