Internet Engineering Task Force T. Hardjono
INTERNET-DRAFT B. Cain
draft-ietf-pim-simplekmp-01.txt Nortel Networks
February 2000 Expires: August 2000
Simple Key Management Protocol for PIM
<draft-ietf-pim-simplekmp-01.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 February 2000
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 February 2000
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 February 2000
- 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 February 2000
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 February 2000
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 February 2000
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 February 2000
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
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821, USA
Tel: +1-978-288-4538
Hardjono, Cain [Page 8]
-------------------------------------------------------------------------
------------------------------------------------------------------------
Thomas Hardjono email1: thardjono@yahoo.com
email2: hardjono@nortelnetworks.com
Tel: +1-978-288-4538
------------------------------------------------------------------------