The Use of G-IKEv2 for Multicast Router Key Management
draft-tran-karp-mrmp-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Brian Weis , Paulina Tran | ||
| Last updated | 2011-10-24 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-tran-karp-mrmp-00
Network Working Group P. Tran
Internet-Draft B. Weis
Intended status: Standards Track Cisco Systems
Expires: April 26, 2012 October 24, 2011
The Use of G-IKEv2 for Multicast Router Key Management
draft-tran-karp-mrmp-00
Abstract
The G-IKEv2 key management protocol protects group traffic, usually
in the form of IP multicast communications between a set of network
devices. G-IKEv2 can be used to protect the communications of
routing protocols using a one-to-many or many-to-many communications
model.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 26, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Tran & Weis Expires April 26, 2012 [Page 1]
Internet-Draft G-IKEv2-MRKM October 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Overview of Group Key Management . . . . . . . . . . . . . . . 3
3. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Header and Payload Formats . . . . . . . . . . . . . . . . . . 6
4.1. Group Security Association Payload . . . . . . . . . . . . 6
4.1.1. GSA TEK Payload . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Tran & Weis Expires April 26, 2012 [Page 2]
Internet-Draft G-IKEv2-MRKM October 2011
1. Introduction
The G-IKEv2 protocol [I-D.yeung-g-ikev2] has been defined to
distribute group policy and keys to a group of network devices. It
re-uses IKEv2 protocols, incorporating payloads similar to GDOI
[RFC6407]. This memo describes a mode of using G-IKEv2 to protect
routing protocols using one-to-many communication models (e.g., OSPF,
PIM), and is known as G-IKEv2for Multicast Router Key Management
(G-IKEv2-MRKM).
1.1. Requirements Language
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 [RFC2119].
2. Overview of Group Key Management
When a group of network devices need to communicate using multicast
communications, the devices need to share keying material and the
policy associated with that keying material. A group key management
(GKM) protocol is used to securely distribute this keying material
and associated policy. Typically each network device (also known as
a group member (GM)) needing to participate in the group "register"
to a group controller/key server (GCKS), during which mutual
authentication and authorization occur. The GCKS also distributes
current group policy and keying material to the group member over an
authenticated and encrypted session. When G-IKEv2 is used, this is
achieved in four messages: two to setup the encrypted session
(identical to the IKEv2 [RFC5996] IKE_INIT protocol, and two to
authenticate, authorize, and distribute group policy to the GM
(similar in construction to the IKEv2 IKE_AUTH protocol).
A GKM protocol typically uses a "rekey" protocol to efficiently
distribute replacement keying material and associated policy to GMs.
However, this is primarly an optimization for scalability. Because
there are likely to be network devices communicating in a routing
protocol, this protocol is less desirable. In this memo, we describe
how the group can utilize the registration protocol for both initial
keying and rekeying purposes.
G-IKEv2-MRKM is a GKM use case where a group of network routers
participating in a multicast routing protocol act as GMs. The choice
of a GCKS is not restricted by this memo, but operationally it is
most reliable for one of the GMs to take that role.
Tran & Weis Expires April 26, 2012 [Page 3]
Internet-Draft G-IKEv2-MRKM October 2011
3. Exchanges
The exchange of private keying material between two network devices
using a dedicated key management protocol is a common requirement.
There is no need to define an entirely new protocol for routing
protocols having this requirement when existing mature protocol
exchanges and methods have been vetted. This memo makes use of the
G-IKEv2 protocol exchanges, state machine, and policy definitions
whenever possible. However, as G-IKEv2 was developed exclusively for
the use of IPsec, these protocol exchanges are incorporated by
reference into the present key protocol definitions, and are
exchanged using a different exchange type Group Initial Exchange
(GSA_INIT) and Group member Authentication exchange (GSA_AUTH)
[I-D.yeung-g-ikev2]. The use of exchange type will clearly
differentiate this protocol from IKEv2.
The following two exchanges enable the group member to register to
the key server to get the policy, traffic selector and keys used to
communicate with others group member.
The GSA_INIT exchange is a two-message exchange allows the group
member and key server devices to negotiate cryptographic algorithms,
exchange nonces, and do a Diffie-Hellman exchange [DH]. At the
conclusion of the GSA_INIT, the group member (e.g., router) and key
server can exchange private messages. For the details of this
exchange, refer to IKE_SA_INIT in RFC 5996.
Group Member(Initiator) Key Server (Responder)
-------------------- ----------------------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ,]
Next, the group member and key server devices perform a GSA_AUTH,
which is substancially the same as the IKE_AUTH exchange defined in
RFC 5996, except that the SA, TSi, TSr payloads are not presented as
policy and traffic selectors are pushed from the key server to group
member using new payloads GSA and KD. The IDg, SEQ, GSA, and KD
payloads are described in Section 4 of [I-D.yeung-g-ikev2]; for the
details of the rest of the exchange please refer to IKE-AUTH in RFC
5996. Section Section 4 of this document includes additional GSA
definitions specifically for the purpose of protecting routing
protocol traffic.
Tran & Weis Expires April 26, 2012 [Page 4]
Internet-Draft G-IKEv2-MRKM October 2011
Group Member (Initiator) Key Server (Responder)
-------------------- ----------------------
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, IDg} -->
<-- HDR, SK {IDr, [CERT,] AUTH,
SEQ], GSA, KD}
In the GSA_AUTH exchange, the group member sends the group
identification that it wants to join or register to. The key server
authenticates and authorizes the group member and pushes the policy,
traffic selector in GSA payload, and the key in the KD payload to the
group member. At the successful conclusion of the GSA_AUTH exchange,
the group member has policy and keying material to securely
communicate with others group members that also registered with the
key server. With this IKEv2 SA established between GM and KS, the GM
can request for policy and keys of an additional group using GSA_PULL
exchange. In GSA_PULL exchange, the GM will send group ID that it
wants to join, the key server response will include sequence (SEQ),
policy (GSA) and key material (KD).
Group Member (Initiator) Key Server (Responder)
-------------------- ----------------------
HDR, SK {IDg} --
<-- HDR, SK { [ SEQ ], GSA, KD}
The group member and key server need to maintain the group
association SA (GSA) to further communicate securely or the
registration process above need to be repeated. Before the policy
and traffic key expired, the key server can use multicast GSA_REKEY
message to PUSH the fresh policy and keys to all its group members.
This exchange is protected by the KEK policy and key sent from the
key server to group member during registration. The key server will
include sequence (SEQ), policy (GSA), and keying material (KD)
payloads in the rekey message. A rekey message might be necessary if
a key lifetime is about to expire, due to concern that a key might
have been compromised, or some other reason.
Group Member (Initiator) Key Server (Responder)
-------------------- ----------------------
<- HDR, SK {SEQ, GSA, KD, AUTH}
The KS can delete group member by sending Delete (D) payloads in the
GSA_REKEY message . The Delete (D) payloads are defined in Section 4
of [I-D.yeung-g-ikev2].
Group Member (Initiator) Server (Responder)
------------------- ------------------
<-- HDR, SK {[D,] ... , AUTH}
Tran & Weis Expires April 26, 2012 [Page 5]
Internet-Draft G-IKEv2-MRKM October 2011
4. Header and Payload Formats
The protocol defined in this memo uses a HDR identical to that
defined in RFC5996. GSA exchange types and payloads described in
this section are added to same IANA registry containing G-IKEv2
definitions.
4.1. Group Security Association Payload
The Group Security Assocation (GSA) payload contains one or more sets
of policy that a router is willing to use to protect a routing
protocol. It is identitcal to the GSA payload described in Section
4.3 of [I-D.yeung-g-ikev2]. This memo makes no changes to this
payload.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! GSA Attribute Next Payload ! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
4.1.1. GSA TEK Payload
One of GSA attribute "next payload" types is the Traffic Encryption
Key (TEK) payload. The TEK payload describes the Traffic Encryption
Policy. This document define new protocol ID of TEK protocol
specific payload for routing protocol OSPFv2, OSPFv3 and PIM.
Tran & Weis Expires April 26, 2012 [Page 6]
Internet-Draft G-IKEv2-MRKM October 2011
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Type ! RESERVED ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Protocol-ID ! TEK Protocol-Specific Payload !
+-+-+-+-+-+-+-+-+ ~
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
Protocol ID Value
----------- -----
RESERVED 0
GSA_PROTO_IPSEC_ESP 1
GSA_PROTO_IPSEC_AH 2
GSA_PROTO_OSPFv2 TBD
GSA_PROTO_OSPFv3 TBD
GSA_PROTO_PIM TBD
4.1.1.1. TEK OSPFv2 Protocol-Specific Payload
TEK OSPFv2 Protocol Specific Payload contains SPI, the authentication
algorithm and key lifetime.
The TEK OSPF protocol specific payload is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SPI ! RESERVED | Auth algo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! GSA life Attributes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
SPI - (1 octet) Secure Parameter Index will be used in OSPFv2
header as Key ID (RFC 2328, Appendix D)
Auth algo - (2 octets) Authentication Algorithm
Keyed-MD5 (defined in RFC 2328, Appendix D)
HMAC-SHA-1 (defined in RFC 5709, Section 3)
HMAC-SHA-256 (defined in RFC 5709, Section 3)
HMAC-SHA-384 (defined in RFC 5709, Section 3)
HMAC-SHA-512 (defined in RFC 5709, Section 3)
GSA Life Attribute - Key lifetime, define in
(draft-yeung-g-ikev2-03, section 4.5)
Tran & Weis Expires April 26, 2012 [Page 7]
Internet-Draft G-IKEv2-MRKM October 2011
4.1.1.2. TEK OSPFv3 and PIM IPsec Protocol-Specific Payload
OSPFv3 and PIM IPSEC protocol specific payload similiar to GIKEv2 TEK
payload for ESP and AH. This payload doesn't include the traffic
selector as protocol-ID value in the GSA TEK payload already indicate
OSPFv3 or PIM traffic.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SPI !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
| 0 (last) or 3 | RESERVED | Transform Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Transform Type | RESERVED | Transform ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Transform Attributes ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ GSA Life Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
SPI (4 octets) - Secure Parameter Index
Transform - Same sa G-IKEv2 TEK transform define in
(draft-yeung-g-ikev2-03, section 4.5)
Where transform type can be 1 (Encryption Algorithm)
for ESP and/or 3 (Integrity Algorithm) for AH.
Description Trans. Used In
Type
----------------------------------------------------------------
Encryption Algorithm (ENCR) 1 ESP
Integrity Algorithm (INTEG) 3 AH, optional in ESP
Extended Sequence Numbers (ESN) 5 AH and ESP
Transform Type 1 (Encryption Algorithm)
Name Number Defined In
---------------------------------------------------
ENCR_NULL 11 (RFC2410)
ENCR_AES_CBC 12 (RFC3602)
Transform Type 3 (Integrity Algorithm)
Tran & Weis Expires April 26, 2012 [Page 8]
Internet-Draft G-IKEv2-MRKM October 2011
Name Number Defined In
----------------------------------------
NONE 0
AUTH_HMAC_MD5_96 1 (RFC2403)
AUTH_HMAC_SHA1_96 2 (RFC2404)
GSA Life Attribute - Key lifetime, define in
(draft-yeung-g-ikev2-03, section 4.5)
5. IANA Considerations
TBD
6. Security Considerations
This document describes a use case of group key management using
G-IKEv2. The security considerations in [I-D.yeung-g-ikev2] directly
apply to this memo.
7. Acknowledgements
Sam Hartman and Dacheng Zhang previously published the MRKMP protocol
[I-D.hartman-karp-mrkmp], which includes many operations and protocol
elements in common with this memo.
8. Normative References
[I-D.hartman-karp-mrkmp]
Hartman, S. and D. Zhang, "Multicast Router Key Management
Protocol (MRKMP)", draft-hartman-karp-mrkmp-01 (work in
progress), March 2011.
[I-D.yeung-g-ikev2]
Rowles, S., Yeung, A., Tran, P., and Y. Nir, "Group Key
Management using IKEv2", draft-yeung-g-ikev2-03 (work in
progress), July 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
Tran & Weis Expires April 26, 2012 [Page 9]
Internet-Draft G-IKEv2-MRKM October 2011
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
of Interpretation", RFC 6407, October 2011.
Authors' Addresses
Paulina Tran
Cisco Systems
170 Tasman Drive
San Jose, California CA
USA
Phone: +1 (408) 526-8902
Fax:
Email: ptran@cisco.com
URI:
Brian Weis
Cisco Systems
170 Tasman Drive
San Jose, California CA
USA
Phone: +1 (408) 526-4796
Fax:
Email: bew@cisco.com
URI:
Tran & Weis Expires April 26, 2012 [Page 10]