One document matched: draft-tran-karp-mrmp-01.txt
Differences from draft-tran-karp-mrmp-00.txt
Network Working Group P. Tran
Internet-Draft B. Weis
Intended status: Standards Track Cisco Systems
Expires: September 10, 2012 March 9, 2012
The Use of G-IKEv2 for Multicast Router Key Management
draft-tran-karp-mrmp-01
Abstract
The G-IKEv2 key management protocol protects group traffic, usually
in the form of IP multicast communications between a set of network
devices. This memo defines extensions to G-IKEv2 allowing it 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 September 10, 2012.
Copyright Notice
Copyright (c) 2012 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 September 10, 2012 [Page 1]
Internet-Draft G-IKEv2-MRKM March 2012
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 . . . . . . . . . . . . . . . . . . 5
4.1. Group Security Association Payload . . . . . . . . . . . . 5
4.1.1. GSA TEK Payload . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Tran & Weis Expires September 10, 2012 [Page 2]
Internet-Draft G-IKEv2-MRKM March 2012
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
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-IKEv2 for 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_SA_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 primarily an optimization for scalability. This
optimization is less desirable for a small group of routing protocol
participants. 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 routing protocol using a multicast transport act
as GMs. Which device takes the role of GCKS is not specified by this
memo, but operationally it is most reliable for one of the GMs to
take that role. Additionally, for routing protocol reliability the
routers may require the ability to use redundant key servers and to
Tran & Weis Expires September 10, 2012 [Page 3]
Internet-Draft G-IKEv2-MRKM March 2012
elect a key server from available group members. This memo does not
address redundancy, however the protocols in this memo should be
compatible with the redundancy strategy described in
[I-D.hartman-karp-mrkmp].
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 extends the
G-IKEv2 protocol exchanges, state machine, and policy definitions.
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 IKE_SA_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 IKE_SA_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 substantially the same as the IKE_AUTH exchange defined in
RFC 5996, except that the SA, TSi, TSr payloads in IKE_AUTH are not
used. Policy and traffic selectors are pushed from the key server to
group member using new payloads GSA and KD. For the details of the
rest of the exchange please refer to Section 4 of
[I-D.yeung-g-ikev2]. Section Section 4 of this document includes
additional GSA definitions specifically for the purpose of protecting
routing protocol traffic.
Group Member (Initiator) Key Server (Responder)
------------------------ ----------------------
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, IDg} -->
<-- HDR, SK {IDr, [CERT,] AUTH,
GSA, KD}
Tran & Weis Expires September 10, 2012 [Page 4]
Internet-Draft G-IKEv2-MRKM March 2012
In the GSA_AUTH exchange, the group member sends the identification
of the group to which it wants to join or register. 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 the
GSA_CLIENT_SERVER exchange. In the GSA_CLIENT_SERVER exchange, the
GM will send group ID that it wants to join, where the key server
response will include policy (GSA) and key material (KD).
Group Member (Initiator) Key Server (Responder)
------------------------ ----------------------
HDR, SK {IDg} -->
<-- HDR, SK { GSA, KD, [D]}
Once a GSA_AUTH has completed the group member and key server MAY
destroy the G-IKEv2 SA. However when the number of group members is
small, as is usually the case for routing protocol participants, it
is RECOMMENDED for them to maintain the G-IKEv2 association SA for
the key server to notify group members that they should re-register
in order to obtain new group policy. This notify exchange replaces a
seperate rekey mechanism optimized for large group.
In some cases, a GCKS may need to change the group policy and/or
rekey before current keys expire. In cases where the G-IKEv2 rekey
protocol is not used the GCKS can send an INFORMATIONAL exchange with
a Notify payload directing the group member to re-register using a
REGISTER_REQUESTED status notify message (value TBD). This event
triggers a GSA_CLIENT_SERVER exchange, as described above. The
response to GSA_CLIENT_SERVER from the KS may include Delete payloads
instructing the group member to delete old SAs.
4. Header and Payload Formats
The protocol defined in this memo uses a HDR 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 identical to the GSA payload described in Section
4.3 of [I-D.yeung-g-ikev2]. This memo makes no changes to this
Tran & Weis Expires September 10, 2012 [Page 5]
Internet-Draft G-IKEv2-MRKM March 2012
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.1. GSA TEK Payload
One of GSA types is the Traffic Encryption Key (TEK) policy. The TEK
describes the Traffic Encryption Policy. This document define new
protocol ID of TEK protocol specific payload for routing protocol
OSPFv2, OSPFv3 and PIM.
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:
Tran & Weis Expires September 10, 2012 [Page 6]
Internet-Draft G-IKEv2-MRKM March 2012
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)
TEK Attribute - Key lifetime, define in
(draft-yeung-g-ikev2-03, section 4.5)
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, because the traffic selectors are well known
and unchanging values. However it should be noted that a site
requiring alternative transforms can use the G-IKEv2 definitions for
ESP and AH to define this policy.
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 ~
Tran & Weis Expires September 10, 2012 [Page 7]
Internet-Draft G-IKEv2-MRKM March 2012
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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)
Name Number Defined In
----------------------------------------
NONE 0
AUTH_HMAC_MD5_96 1 (RFC2403)
AUTH_HMAC_SHA1_96 2 (RFC2404)
TEK Attribute - Key lifetime, define in
(draft-yeung-g-ikev2-03, section 4.5)
5. IANA Considerations
G-IKEv2 [I-D.yeung-g-ikev2] defines a new registry. This memo adds
the following definitions to this registry. (TBD)
Tran & Weis Expires September 10, 2012 [Page 8]
Internet-Draft G-IKEv2-MRKM March 2012
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. References
8.1. Normative References
[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,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
8.2. Informative References
[DH] Diffie, W. and M. Hellman, "New Directions in
Cryptography", IEEE Transactions on Information
Theory, V.IT-22 n. 6, June 1977.
[I-D.hartman-karp-mrkmp]
Zhang, D., Lebovitz, G., and S. Hartman, "Multicast Router
Key Management Protocol (MaRK)",
draft-hartman-karp-mrkmp-03 (work in progress),
January 2012.
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
of Interpretation", RFC 6407, October 2011.
Tran & Weis Expires September 10, 2012 [Page 9]
Internet-Draft G-IKEv2-MRKM March 2012
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 September 10, 2012 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-23 22:21:25 |