Internet DRAFT - draft-tran-karp-mrmp
draft-tran-karp-mrmp
Network Working Group P. Tran
Internet-Draft B. Weis
Intended status: Standards Track Cisco Systems
Expires: April 25, 2013 October 22, 2012
The Use of G-IKEv2 for Multicast Router Key Management
draft-tran-karp-mrmp-02
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 routing protocols between a group of network devices.
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 25, 2013.
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 April 25, 2013 [Page 1]
Internet-Draft G-IKEv2-MRKM October 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 . . . . . . . . . . . . . . . . . . 6
4.1. Group Security Association Payload . . . . . . . . . . . . 6
4.1.1. GSA TEK Policy . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Tran & Weis Expires April 25, 2013 [Page 2]
Internet-Draft G-IKEv2-MRKM October 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 (e.g., OSPF, PIM) and is known as G-IKEv2 for
Multicast Router Key Management (G-IKEv2-MRKM). Two models of group
security are discussed.
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 "registers"
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.
Many routing protocols are designed such that each participating
network device sources network packet that one or more peers receive,
often using link-local multicast addresses. Using GKM terminology,
this is an M-to-N communication model [RFC3740], which provides for
many senders and receivers. However, varying group security models
are possible. Two relevant examples are:
o Multiple-sender security associations. Each network devices
protects packets using the same keying material and policy,
distributed by a single GCKS. When network devices require high
reliability a single GCKS is not sufficient, so may require an
election among currently available authorized members to choose a
GCKS before network communications can be protected. This
approach is taken in [I-D.hartman-karp-mrkmp]. A simpler approach
may be found by requiring all election messages to be
authenticated, which effectively sets up a full mesh of
authenticated connections.
Tran & Weis Expires April 25, 2013 [Page 3]
Internet-Draft G-IKEv2-MRKM October 2012
o Single-sender security associations. Each network device sending
routing protocol packets acts as its own key server, essentially
converting an M-to-N communication model to M 1-to-N groups (where
M is the number of authorized members participating in the routing
protocol). A full mesh of authenticated connections is again
required, but the lack of an election protocol may result in a
simpler system.
The methods in the memo support both Multiple-sender security
associations and single-sender security associations.
The G-IKEv2 GKM protocol provides for a GM receiving security
associations from a GCKS in two IKEv2 exchanges: the IKE_SA_INIT
exchange [RFC5996] to setup the encrypted session, and the GSA_AUTH
exchange [I-D.yeung-g-ikev2] (similar in construction to the IKEv2
IKE_AUTH protocol) to authenticate, authorize, and distribute group
policy.
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,]
Figure 1: IKEv2 IKE_SA_INIT Exchange
Next, the group member and key server devices perform a GSA_AUTH,
which is substantially the same as the IKE_AUTH exchange defined in
Tran & Weis Expires April 25, 2013 [Page 4]
Internet-Draft G-IKEv2-MRKM October 2012
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}
Figure 2: G-IKEv2 GSA_AUTH Exchange
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 ]}
Figure 3: G-IKEv2 GSA_CLIENT_SERVER Exchange
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
separate 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
Tran & Weis Expires April 25, 2013 [Page 5]
Internet-Draft G-IKEv2-MRKM October 2012
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. Alternatively, the
GCKS policy may support the G-IKEv2 group maintenance channel and the
GCKS can distribute a GSA_REKEY exchange with new policy and keying
material (see Section 3.3 of [I-D.yeung-g-ikev2]).
4. Header and Payload Formats
The protocol defined in this memo uses IKEv2 and G-IKEv2 payload
definitions. However, new security policy definitions are described
to support security transforms and policy defined by routing protocol
documents. When a routing protocol indicates the use of ESP or AH,
existing G-IKEv2 SA Payload types suffice.
4.1. Group Security Association Payload
The Group Security Association (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
payload.
4.1.1. GSA TEK Policy
One of the GSA types is the Traffic Encryption Key (TEK) policy. The
TEK describes the Traffic Encryption Policy defined by a supported
security protocol. Some routing protocol definitions (i.e., OSPFv3
[RFC4552], LMP [RFC4204], and PIM [RFC5796]) describe the use of ESP
and AH, which are supported by existing G-IKEv2 TEK policy
definitions. However, a number of routing protocol specific security
transforms exist and these require new TEK definitions.
Section 4.5 of [I-D.yeung-g-ikev2] defines the TEK payload as a
Protocol-ID followed by a TEK Protocol-Specific Payload, replicated
in Figure 4 for reference.
Tran & Weis Expires April 25, 2013 [Page 6]
Internet-Draft G-IKEv2-MRKM October 2012
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 !
+-+-+-+-+-+-+-+-+ ~
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
Figure 4: GSA TEK Payload
This memo extends the list of Protocol-ID values to include a set of
routing protocols that use group keys, shown in Figure 5.
Protocol-ID Value
----------- -----
RESERVED 0
GSA_PROTO_IPSEC_ESP 1
GSA_PROTO_IPSEC_AH 2
GSA_PROTO_OSPFv2 TBD1
GSA_PROTO_OSPFv3 TBD2
GSA_PROTO_IS_IS TBD3
GSA_PROTO_LDP_HELLO TBD4
GSA_PROTO_RSVP_TE TBD5
GSA_PROTO_BFD TBD6
Figure 5: Routing Protocol-ID Values
4.1.1.1. TEK Protocol-Specific Payload
The policy for each of the new Protocol-ID types defines in this memo
are sufficiently similar that a single Routing Protocol (RP)
protocol-specific payload that can be defined to convey the required
policy. Figure 6 defines the RP-TEK payload.
Tran & Weis Expires April 25, 2013 [Page 7]
Internet-Draft G-IKEv2-MRKM October 2012
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 Size | SPI (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
| |
~ <Source Traffic Selector> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <Destination Traffic Selector> |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
| |
~ <Transforms> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! TEK Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
Figure 6: RP TEK Protocol-Specific Payload
The RP-TEK fields are defined as follows:
o SPI Size (1 octet) - Equal to the size, in octets, of the SPI
defined by the corresponding protocol.
o SPI (variable) - The SPI defined by the GCKS representing this
TEK. In many cases, the SPI is referred to as a Key ID by routing
protocol specifications.
o Source & Destination Traffic Selectors - The traffic selectors
describe the source and the destination of the protecting traffic.
The format and values are defined in IKEv2 [RFC5996], section
3.13.1.
o Transforms - One or more substructures specifying the transform
information. The format is defined in IKEv2 [RFC5996], section
3.3.2.
o TEK Attributes - Contains TEK policy attributes associated with
the group. The following sections describe the possible
attributes. Any or all attributes may be optional, depending on
the group policy. [RFC5996], section 3.3.5.
Attributes
Tran & Weis Expires April 25, 2013 [Page 8]
Internet-Draft G-IKEv2-MRKM October 2012
Attribute Type Value Attribute Format
------------------------------------------------------------
Life Duration 1 TLV
Specifies the time-to-live for the overall security association.
When the TEK expires, all keys downloaded under the association (AH
or ESP) must be re-rekeyed. The life duration attribute defines the
actual length of the component lifetime in seconds that can be
protected. If unspecified, there is no lifetime defined for the TEK.
Attribute Type Value Attribute Format
------------------------------------------------------------
Replay Protection 2 TV
Some routing protocols (e.g., RSVP-TE) define multiple replay
protection methods. Possible values of the Replay Protection
attribute are:
+-------+---------+
|Number |Name |
+-------+---------+
| 0 |NONE |
| 1 |COUNTER |
| 2 |TIME |
+-------+---------+
Figure 7: RP Replay Method Attributes
4.1.1.2. Transforms
Policy for each of the routing protocols differs, but it possible to
summarize the policy into one or more transform types. The following
sections describe this policy.
4.1.1.2.1. Integrity Algorithms
Routing protocols include an integrity algorithm, often but not
always an HMAC construction. The following table represents current
integrity algorithms specified by each routing protocol considered in
the KARP charter.
Tran & Weis Expires April 25, 2013 [Page 9]
Internet-Draft G-IKEv2-MRKM October 2012
+--------+-------------------------------------------------+----------+
| RP | Integrity Algorithm Name(s) | RFC |
+--------+---------------------------------+---------------+----------+
| OSPFv2 |Keyed-MD5 | RFC 2328 |
| |HMAC-SHA-1,HMAC-SHA-256,HMAC-SHA-384,HMAC-SHA-512| RFC 5709 |
| OSPFv3 |HMAC-SHA-1,HMAC-SHA-256,HMAC-SHA-384,HMAC-SHA-512| RFC 6506 |
| IS-IS |HMAC-MD5 | RFC 5304 |
| |HMAC-SHA-1,HMAC-SHA-224,HMAC-SHA-256,HMAC-SHA-384| RFC 5310 |
| |HMAC-SHA-512 | RFC 5310 |
| LDP |HMAC-SHA-1,HMAC-SHA-256,HMAC-SHA-384,HMAC-SHA-512| (LDP I-D)|
| RSVP-TE|HMAC-MD5 | RFC 2747 |
| BFD |Keyed-MD5, Keyed-SHA1,Meticulous-Keyed-SHA1 | RFC 5880 |
| |HMAC-SHA-256,HMAC-SHA-384,HMAC-SHA-512 | (BFD I-D)|
+-------+----------------------------------+---------------+----------+
(LDP I-D) [I-D.ietf-mpls-ldp-hello-crypto-auth] (BFD I-D)
[I-D.ietf-bfd-generic-crypto-auth]
Figure 8: Survey of RP Integrity Algorithms
None of these are currently represented as current IKEv2 INTEG
transform values, primarily because the output has not been defined
by the routing protocol transforms to be truncated. Since these
transforms are mutually exclusive to the transforms defined in the
Transform Type 3 - Integrity Algorithm Transform IDs IKEv2 IANA
table, and to reduce confusion between IPsec integrity transform
values and routing protocol transform values, this memo defines a new
transform to describe the routing protocol integrity transforms.
Transform IDs for the RP-INTEG Transform attributes types are shown
in Figure 9. Attributes
+-------+-----------------------+
|Number | Name |
+-------+-----------------------+
| 0 |RP_AUTH_HMAC_MD5 |
| 1 |RP_AUTH_HMAC_SHA1 |
| 2 |RP_AUTH_HMAC_SHA2_224 |
| 3 |RP_AUTH_HMAC_SHA2_256 |
| 4 |RP_AUTH_HMAC_SHA2_384 |
| 5 |RP_AUTH_HMAC_SHA2_512 |
| 6 |RP_AUTH_KEYED_MD5 |
| 7 |RP_AUTH_KEYED_SHA1 |
| 8 |RP_AUTH_MET_KEYED_SHA1 |
+-------+-----------------------+
Figure 9: RP-INTEG Transform IDs
Tran & Weis Expires April 25, 2013 [Page 10]
Internet-Draft G-IKEv2-MRKM October 2012
4.1.1.2.2. Extended Sequence Numbers
Some routing protocol transforms have introduced a 64-bit sequence
number. This can be signaled using the Extended Sequence Numbers
Transform. No changes are required to the Extended Sequence Numbers
Transform.
5. IANA Considerations
G-IKEv2 [I-D.yeung-g-ikev2] defines a new registry. This memo adds
the following definitions to this registry. (TBD)
A new IKEv2 Transform (RP_INTEG) is defined for declaring routing
protocol integrity algorithms.
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-05 (work in
progress), October 2012.
[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.
Tran & Weis Expires April 25, 2013 [Page 11]
Internet-Draft G-IKEv2-MRKM October 2012
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]
Hartman, S., Zhang, D., and G. Lebovitz, "Multicast Router
Key Management Protocol (MaRK)",
draft-hartman-karp-mrkmp-05 (work in progress),
September 2012.
[I-D.ietf-bfd-generic-crypto-auth]
Bhatia, M., Manral, V., and D. Zhang, "BFD Generic
Cryptographic Authentication",
draft-ietf-bfd-generic-crypto-auth-03 (work in progress),
October 2012.
[I-D.ietf-mpls-ldp-hello-crypto-auth]
Zheng, L., Chen, M., and M. Bhatia, "LDP Hello
Cryptographic Authentication",
draft-ietf-mpls-ldp-hello-crypto-auth-00 (work in
progress), August 2012.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, March 2004.
[RFC4204] Lang, J., "Link Management Protocol (LMP)", RFC 4204,
October 2005.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, June 2006.
[RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and
Confidentiality in Protocol Independent Multicast Sparse
Mode (PIM-SM) Link-Local Messages", RFC 5796, March 2010.
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
of Interpretation", RFC 6407, October 2011.
Tran & Weis Expires April 25, 2013 [Page 12]
Internet-Draft G-IKEv2-MRKM October 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 April 25, 2013 [Page 13]
