Internet Draft Internet Engineering Task Force T. Hardjono INTERNET-DRAFT B. Cain draft-ietf-pim-simplekmp-00.txt Nortel Networks February 19, 1999 Expires: August 19, 1999 Simple Key Management Protocol for PIM <draft-ietf-pim-simplekmp-00.txt> 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 describes a simple key management approach for the PIM multicast routing protocol, observing the key arrangement for PIM defined in [Wei98] for PIM version 2. 1. Introduction The PIM Working Group (IETF) has recently put forward a proposal [Wei98] on the arrangement of cryptographic keys within a given PIM domain, with the aim of deploying the keys for control-packet authentication in the PIM domain. Although the proposal suggests a key arrangement, it purposely does not specify how the keys are to be delivered to the relevant network entities in the PIM domain. The current work covers a key distribution method based on the use of a combination of public key cryptography and private key cryptography. A Domain Key Distributor (DKD) entity is introduced which performs the initial dissemination of keys in the domain and the re-keying of the keys on a periodic basis. Hardjono, Cain [Page 1] INTERNET DRAFT 19 February 1999 The current work aims at a limited form of key management specifically for PIM, anticipating the development of a generic key management standard in the future. Although the solutions described here are PIM-specific, some of the methods can be developed further for a generic key management framework. 2. Background Following [Wei98], when security is enabled, all PIM version 2 messages will carry an IPSEC [KS98a] authentication header (AH) [KA98c]. The authentication mechanism MUST support HMAC-MD5-96 [MG98a,Riv92] and HMAC-SHA-1-96 [MG98b] security transformations. The PIM key arrangement of [Wei98] identifies the following entities in a PIM domain that require keys: the BootStrap Router (BSR), the Rendezvous Point (RP), the Designated Router (DR) and other PIM routers. All keys are relevant and recognized only within one PIM domain. For clarity, here we denote the following symbols for the respective keys described in [Wei98]. Public key pairs are described using the symbol SK ("Secret Key") and PK ("Public Key"), whereas private (symmetric) keys are described using the symbol "K" with the appropriate notation. The keys are defined as follows: - All PIM routers in the same domain still share a single secret (the "equal opportunity" key) that is used to compute digests for PIM messages. This key is denoted as Keq. - All BSRs own an identical RSA [RSA93] key pair and uses the private key to sign an entire bootstrap message, whilst other routers only have the public key to verify the signature. This RSA secret-public key pair is denoted as (SKbsr, PKbsr). This allows only authorized candidate BSRs to become a bootstrap router. - All RPs and BSRs share another symmetric key, known as the "RP-key" and denoted here as Krp. No other routers have this key. For candidate RP advertisement the digest is only calculated with the RP-key Krp (instead of the equal opportunity key Keq). This achieves the effect that only the authorized candidate RPs can advertise their candidacy to the BSR. For convenience the keys of [Wei98], namely RSA key-pair (PKbsr, SKbsr), Keq and Krp, will be referred to subsequently as "Primary Keys" in order to distinguish them from other cryptographic keys. Hardjono, Cain [Page 2] INTERNET DRAFT 19 February 1999 3. Key-Management Keys: Assignments In order to deliver the relevant primary keys specified in [Wei98], we define a further set of keys, which will be referred to as "Key Management Keys" (KM-Key). These keys are long-term keys whose use is primarily for delivering the Primary Keys. Thus unlike the Primary Keys which are used frequently on control-messages, the KM-keys need not be rekeyed very often. - The Domain Key Distributor (DKD) is assigned the RSA key pair (PKdkd, SKdkd). Following the "semi-public" usage of public key technology, the key PKdkd is only known by PIM-routers within the domain. Only the DKD knows SKdkd. - All Candidate-RPs (namely the routers from which the set of RPs will be selected) and the BSR are assigned the "semi-public" RSA public key PKrpbsr, whose matching secret half SKrpbsr is only known to the DKD. The DKD also knows PKrpbsr. Note that all RPs share the same PKrpbsr. Note that all public key pairs defined in the current document is used in a "semi-public" or "closed" system, in which only certain designated entities know the public-key of other entities. All keys are uniquely functioning within only one PIM domain. Hence, implicit authentication is achieved through the limited sharing of the public-keys among certain entities, while confidentiality can established by the holder of the secret-key by enciphering messages to be sent using the secret-key. The BSR key pair (SKbsr, PKbsr) will also be used on occasion for supporting key-management. In the remainder of the current document, timestamping, nonces and other anti-replay mechanisms are assumed to be incorporated, both in the initial dissemination of keys and in their subsequent re-keying. 4. Initial Key Dissemination In order to kick-start the key management process, two avenues are possible. The first is by manual configuration, while the second is based on a secure channel opened between the DKD and each PIM router. A. Manual Configuration Here all the following keys must be manually configured into the corresponding entities: - the key PKdkd of the DKD is manually configured into all PIM-routers (including the BSR and RPs) Hardjono, Cain [Page 3] INTERNET DRAFT 19 February 1999 - the pair (PKbsr, SKbsr) is manually configured into the BootStrap Router (BSR) - the key PKrpbsr is manually configured into the BSR and the RPs. B. Online Dynamic Configuration This approach requires each router Ri to have a global public key pair (PKri, SKri), which may be manually configured or loaded manually, preferably using a secure method (eg. smartcard). Using its public key pair, a router in the domain establishes a Security Association (SA) and a secure channel with the DKD. - The BSR can either generate the pair (PKbsr, SKbsr) and then upload a copy of PKbsr to the DKD through the secure channel, or the DKD can generate the pair (PKbsr, SKbsr) and download the pair to the BSR through the secure channel. - The BSR must download a copy of the key PKrpbsr (generated by the DKD) from the DKD through the secure channel. - All RPs must download a copy of the key PKrpbsr (generated by the DKD) through a secure channel which they individually establish with the DKD. - All PIM routers must download a copy of the key PKdkd (generated by the DKD) through a secure channel which they individually establish with the DKD. 5. Dissemination of other Primary Keys Through the initial key dissemination process (above), only the key pair (PKbsr, SKbsr) of the Primary Key have been disseminated to the BSR. What remains is the dissemination of the other Primary Keys to the other relevant entities. This is discussed in the following. 5.1 Disseminating PKbsr to All PIM-Routers The DKD digitally-signs the public key PKbsr (using its secret-key SKdkd) and sends the result to all PIM-routers in the domain, either through unicast or through the distribution tree itself (eg. the "All-PIM-Routers" group). In effect, the DKD vouches for the BSR. Only PIM-routers (holding PKdkd) can verify the signature. If confidentiality is needed, then the DKD can encrypt PKbsr rather than digitally signing it. Hardjono, Cain [Page 4] INTERNET DRAFT 19 February 1999 5.2 Disseminating Krp shared by BSR and RPs The DKD must encrypt Krp using the secret-key SKrpbsr (known only to the DKD) and send the resulting ciphertext to the BSR and all RPs. This can be done by multicasting to the special "All-PIM-Routers" group in the domain. Since only the BSR and RPs have the matching key PKrpbsr, only they will be able to decipher the message to obtain the key Krp. All other PIM-routers will drop this message (unreadable). 5.3 Disseminating Keq for all PIM-routers The DKD encrypts the equal-opportunity-key Keq using its secret-key SKdkd and sends the ciphertext to all PIM-routers in the domain, either through unicast or through the distribution tree (eg. the "All-PIM-Routers" group). Since only PIM-routers have the "semi- public" key PKdkd, only PIM routers will be able to decipher the ciphertext to obtain Keq. All other routers will drop this message (unreadable). 6. Re-Keying the Primary Keys: Strategy The nature of public keys versus private keys requires their re- keying to be carried-out in differing manners. In the following, the re-keying of each of the Primary Keys is discussed, with some available options being described. In order to distinguish the old keys and the fresh keys, the numbers "1" is attached to the old keys and the number "2" is attached to the fresh keys. 6.1 Re-keying the BSR keys using installed keys: The first step in the re-keying of the BSR public key pair consist of re-keying the BSR entity itself first. Two options are available depending on whether the BSR or the DKD generates the new key pair. A. If the DKD generates the new key pair (SKbsr2, PKbsr2), then it must deliver the pair to the BSR. This can be done as follows: (1) The DKD encrypts (or digitally-signs) the new pair (SKbsr2, PKbsr2) under the DKD's secret-key (SKdkd) resulting in a ciphertext Cbsr. (2) The DKD further encrypts the ciphertext Cbsr with the current BSR public-key PKbsr1 resulting in a ciphertext CCbsr. The DKD then unicasts the final ciphertext CCbsr (containing the new key) to the BSR. Only the BSR holding SKbsr1 will be able to decipher CCbsr. Hardjono, Cain [Page 5] INTERNET DRAFT 19 February 1999 B. If the BSR generates the new key pair (SKbsr2, PKbsr2), then it must deliver the public half PKbsr2 to the DKD. This can be done as follows: (1) The BSR encrypts (or digitally-signs) the new key PKbsr2 under the BSR's current secret-key (SKbsr1) resulting in a ciphertext Cdkd. (2) The BSR further encrypts the ciphertext Cdkd with the current DKD public-key PKdkd resulting in a ciphertext CCdkd. The DKD then unicasts the final ciphertext CCdkd (containing the new key) to the DKD. Only the DKD holding SKdkd will be able to decipher CCdkd. 6.2 Re-keying the BSR keys using a separate secure channel: An alternative approach is for a separate secure channel to be created between the DKD and the BSR through the existing security associations. The BSR can either generate the new pair (PKbsr2, SKbsr2) and then upload a copy of PKbsr2 to the DKD through the secure channel, or the DKD can generate the pair (PKbsr2, SKbsr2) and download the pair to the BSR through the secure channel. 6.3 Re-keying Krp: The key Krp shared between the BSR and the RPs can be re-keyed using the previous method (Section 5.2) or using the existing key Krp1. Here we assume that the DKD generates the new Krp2 for equality between the BSR and RPs, and for simplicity. The method to re-key using the existing Krp1 is as follows: (1) The DKD encrypts (or digitally-signs) the new key Krp2 under the DKD's secret-key SKdkd resulting in a ciphertext Crp. (2) The DKD encrypts the ciphertext Crp with the existing key Krp1 resulting in a ciphertext CCrp. The DKD then unicasts CCrp to the BSR and each RP, or the DKD multicasts CCrp to the special "All-PIM-Routers" group in the domain. Only the BSR and the RPs will be able to decipher CCrp since only they hold Krp1. All other PIM-routers will drop this message (unreadable) Hardjono, Cain [Page 6] INTERNET DRAFT 19 February 1999 6.4 Re-keying Keq in all PIM-routers: Since all PIM-routers hold Keq1 and hold the DKD's "semi-public" key PKdkd, the best way to replace Keq1 with a new key Keq2 is using the previous method (Section 5.3). That is, the DKD encrypts the new Keq2 using its secret-key SKdkd and multicasts the ciphertext to all PIM-routers in the domain. Only PIM-routers holding PKdkd will be able to obtain Keq2. All other routers will drop this message (unreadable). Here, for simplicity, we assume that the DKD generates the new Keq2. A combined method can also be adopted, employing the DKD's key and the existing Keq1: (1) The DKD digitally-signs the new key Keq2 using the DKD's secret-key SKdkd resulting in a digest. (2) The DKD encrypts the pair (Keq2, digest) under the existing key Keq1 resulting in a ciphertext CCeq. The DKD then multicasts CCeq to all PIM-routers in the domain. Only PIM-routers holding Keq1 will be able to decipher CCeq to obtain Keq2. All other routers will drop this message (unreadable). 7. Interdomain control-message authentication The current key management approach is limited to a single PIM- domain due to the use of public keys in a "closed" fashion (ie. "semi-public"), where the public half of the keys are made known only to a limited number of entities. Currently, in order to allow some control-messages from a PIM-entity in a PIM-domain D1 to cross the domain boundary to another PIM- entity in a different PIM-domain D2, the DKDs in the respective domains must be assigned global public keys in the traditional (fully-public) manner of use of public keys. Through these global public keys the DKDs can negotiate a intermediate-key used by a PIM- entity in domain D1 to communicate (with authentication and/or confidentiality) with another PIM-entity in another domain D2. In other words, the DKD in a domain vouches for all the PIM-entities in its domain. An improvement over this approach would be for each PIM-entity to be assigned a long-term global public key pair. This would allow router-to-router authentic and/or confidential communications across domain boundaries, without the intervention of the DKDs of the Hardjono, Cain [Page 7] INTERNET DRAFT 19 February 1999 respective domains. Furthermore, it would allow the DKD of a domain to create a secure channel with individual routers in its domain in order to carry-out key management and other network management functions securely. 8. References [Wei98] L. Wei, "Authenticating PIM version 2 messages", IETF internet-draft, draft-ietf-pim-v2-auth-00.txt. [KA98a] S. Kent and R. Atkinson, "Security Architecture for the Internet Protocol", IETF, RFC 1825, 1998. [KA98c] S. Kent and R. Atkinson, "IP Authentication Header", Internet Draft, July 1998. [Riv92] R. Rivest, "MD5 Digest Algorithm", RFC1321, April 1992. [RSA93] RSA Laboratories, "PKCS#1: RSA Encryption Standard", Volume1.5, No. 1993. [MG98a] C. Madson, R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", "draft-ietf-ipsec-auth-hmac-md5-96-03.txt", Feb 1998 [MG98b] C. Madson, R Glenn "The Use of HMAC-SHA-1-96 within ESP and AH", "draft-ietf-ipsec-auth-hmac-sha1-96-03.txt", Feb, 1998 9. Author's Addresses Thomas Hardjono Email: thardjono@baynetworks.com Brad Cain Email: bcain@baynetworks.com Bay Architecture Lab Nortel Networks 3 Federal Street, BL3-03 Billerica, MA 01821, USA Tel: +1-978-916-4538 Hardjono, Cain [Page 8]