Internet Engineering Task Force Y. Liu
Internet Draft Huawei
Expires: January 2008 R. White
B. Weis
M. Barnes
Cisco
July 7, 2007
OSPFv3 Automated Group Keying Requirements
draft-liu-ospfv3-automated-keying-req-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
This document MAY only be posted in an Internet-Draft.
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
This Internet-Draft will expire on January 26, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Liu, et. al. Expires January 7, 2008 [Page 1]
Internet-Draft OSPFv3 Automated Group Keying Reqs July 2007
Abstract
RFC4552 describes how to provide authentication/confidentiality to
OSPFv3 using IPsec. It specifies that same IPsec SA parameters be
configured for both inbound and outbound SAs to provide the "one to
many" security for multicast OSPFv3 communications over broadcast
links (e.g., Ethernet). Manual keying is specified as the mandatory
and default group key management solution. However, issues of
scalability and security exist with manual keying. It is better to
replace manual keying with automated group key management. This
document discusses the requirements on OSPFv3 automated group key
management, assuming that the centralized group key management
architecture introduced in [RFC4046] is used.
Liu, et. al. Expires January 7, 2008 [Page 2]
Internet-Draft OSPFv3 Automated Group Keying Reqs July 2007
Table of Contents
1. Introduction..................................................4
2. Terminology...................................................4
3. General Requirements..........................................5
3.1. Authentication and Authorization of Routers..............5
3.2. Secure Distribution of Group SA..........................6
3.3. Storing Capability of Keys, Authorizations, and Policies.6
4. GCKS Deployment Example and its Specific Requirements.........6
4.1. Decentralized GCKSs......................................7
4.1.1. Single Point of GCKS Failure........................8
4.1.2. GCKS Selecting/Switchover Issue.....................8
4.1.3. Authorization and Authentication of GCKS............8
4.1.4. New Joiner Issue....................................8
4.2. Decentralized KSs, Centralized GC........................9
4.2.1. Bootstrapping Issue.................................9
4.2.2. New Joiner Issue....................................9
4.2.3. Authorization and Authentication of KS..............9
4.3. Decentralized Delegates, Centralized GCKS...............10
4.3.1. Bootstrapping Issue................................10
4.3.2. New Joiner Issue...................................10
4.3.3. Single Point of Delegate Failure...................10
4.3.4. Delegate Selecting/Switchover Issue................11
4.3.5. Authorization and Authentication of Delegate.......11
5. Security Considerations......................................11
5.1. Decentralized GCKS......................................11
5.2. Decentralized KS, Centralized GC........................11
5.3. Decentralized Delegate, Centralized GCKS................11
6. IANA Considerations..........................................11
7. Acknowledgments..............................................12
8.1. Normative References....................................12
8.2. Informative References..................................13
Author's Addresses..............................................14
Intellectual Property Statement.................................15
Full Copyright Statement........................................15
Acknowledgment..................................................15
Liu, et. al. Expires January 7, 2008 [Page 3]
Internet-Draft OSPFv3 Automated Group Keying Reqs July 2007
1. Introduction
OSPFv3 [RFC2740] relies on IPSec to provide integrity, authentication,
and/or confidentiality. RFC4552 describes how to provide
authentication/confidentiality to OSPFv3 using AH/ESP. In Section 7
of RFC4552, it is proved that best scalability and feasibility can be
achieved if the same parameters are used for both inbound and
outbound AH/ESP SAs to provide the "one to many" communication
security while running OSPFv3 over broadcast interfaces. It means
that group security model be used to protect OSPFv3 multicast
communications over broadcast network.
However, RFC4552 specifies Manual Keying [RFC4301] as the default
group key management method, which is neither scalable nor secure.
This document discusses replacing manual keying with automated keying
using either a "one to many" or "many to many" communication model.
It is based on the fact that several GKM protocols have been, or
being, standardized by MSEC working group [RFC3547] [RFC3830]
[RFC4535] [GKDP], which makes it feasible to provide automated group
key management for OSPFv3 using GKM protocols.
Meanwhile, [I-D: draft-ietf-msec-ipsec-extensions] describes
multicast extensions to IPsec, which makes it feasible to provide
group security to OSPFv3 using standard multicast IPsec.
This document describes the requirements on OSPFv3 automated group
key management. It is assumed that the centralized group security
architecture [RFC3740] and group key management architecture [RFC4046]
would be used, where group SAs are centrally managed on separate key
server(s). And one of MSEC GKM protocols will be chosen as the group
keying protocols. Use of group key agreement techniques, for example,
Cliques [CLIQUES], is out of consideration.
2. Terminology
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.
Group Key Management (GKM) Protocol
A group key management protocol used by a GCKS to distribute
IPsec Security Association policy and keying material. A GKM
protocol is used when a group of IPsec devices require the same
SAs. For example, when an IPsec SA describes an IP multicast
destination, the sender and all receivers MUST have the group SA.
Liu, et. al. Expires January 7, 2008 [Page 4]
Internet-Draft OSPFv3 Automated Group Keying Reqs July 2007
Group Controller Key Server (GCKS)
A Group Key Management (GKM) protocol server that manages IPsec
state for a group. A GCKS authenticates and provides the IPsec SA
policy and keying material to GKM group members.
GC and KS may also be acted by different entities. GC is
responsible defining and distributing group policy and
authorization, while KS providing group keying service to a
specific group.
Group Member
An IPsec device that belongs to a group. A Group Member is
authorized to be a Group Speaker and/or a Group Receiver.
Group Security Association (Group SA/GSA)
A collection of IPsec Security Associations (SAs) and GKM SAs
necessary for a Group Member to receive key updates. A GSA
describes the working policy for a group. Refer to RFC 4046
[RFC4046] for additional information.
State Synchronization (SS)
A generalization of OSPFv3 communications that occur after two
routers discover each other. It includes neighbor discovering,
exchanging DDs and LSAs, etc.
3. General Requirements
Requirements discussed in this section are considered general to all
keying solutions.
3.1. Authentication and Authorization of Routers
When a router uses a GKM protocol to contact a GCKS, the GCKS
authenticates the router and verifies that the router is authorized
to participate in the group. Both steps are necessary in order for
the Group SA to ensure that the Group SA is kept private to OSPF
routers that are allowed to participate in OSPF. Both authentication
and authorization MUST be enforced before a Group SA is distributed
to a router.
Liu, et. al. Expires January 7, 2008 [Page 5]
Internet-Draft OSPFv3 Automated Group Keying Reqs July 2007
3.2. Secure Distribution of Group SA
Eavesdroppers are not able to access the group keys by intercepting
the group SA distribution packets. All existing GKM protocols can
meet this requirement.
3.3. Storing Capability of Keys, Authorizations, and Policies
It is expected that a network start up autonomously without a
provisioning step after rebooting. To actualize that target, routers
SHOULD to be able to store group security context information, such
as group policy, authorization, neighbor list, and GSA, etc., in
their storages (i.e., flash, hard disk). After rebooting, if this
policy is stored a router quickly resumes its group security context
to the same state as that of before rebooting and keeps in
synchronization with its neighbors. After every router has done that,
the OSPF SS process can be securely re-done in the network. Fast
routes convergence is assured during this process.
Group security context may change during rebooting. In such cases,
synchronization of group security context among routers can not be
achieved just by caching and resuming mechanisms. Other measures are
needed. Specific requirements on this topic will be discussed case by
case in the following sections.
4. GCKS Deployment Example and its Specific Requirements
MSEC GKM protocols, such as GSAKMP and GDOI, are based on a
client/server model. This means these protocols rely on reachability
between clients and servers for the clients to obtain the group SA
from the server. In this case, the GKM is providing protection for
OSPF, which is an essential component in providing reachability
between the clients and servers. Hence, the client/server model
breaks down in this situation.
To overcome this problem, the group SA must be locally available to
each group member (each OSPFv3 router). Possible solutions to this
circular dependency and their specific requirements are presented in
this section.
The expected network where OSPFv3 multicast communications occur and
group SA is assumed to be deployed is like the network N1 shown in
Fig.1. This network is used in this memo to derive the specific
requirements.
Liu, et. al. Expires January 7, 2008 [Page 6]
Internet-Draft OSPFv3 Automated Group Keying Reqs July 2007
N2 N3
+-----+ +-----+
| |
|2 |
+---+ +---+
|RT1| |RT2|
+---+ +---+
|1 |1
N1 | |
+------------------------------------+
| | |
|1 |1 |1
+---+ +---+ +---+
|RT3| |RT4| |RT5|
+---+ +---+ +---+
| | |
| | |
+-----+ +-----+ +-----+
N4 N5 N6
Figure 1 : The scenario used to derive the requirements
N1 is a broadcast network, where GSA is used to protect the OSPFv3
multicast communications among RT1~RT5. Group members attached to N1,
including RT1~RT5, get the group SA from GCKS. For convenience of
this example, broadcast interfaces attached to N1 are numbered as #1,
which each router recognizes is part of a single group.
Types of networks N2~N6 are not fixed. They MAY be either broadcast,
P2MP, or NBMA. It is assumed that a GSA plays locally on a multicast
network. Whether N2~N6 will share the same GSA with N1 is out the
scope of this memo even if they are broadcast type either.
4.1. Decentralized GCKSs
In this deployment example, there will be a GCKS for each multicast
network. The GCKS may be either a physical server or a logical one
that is acted by an OSPFv3 router, e.g., one router from RT1~RT5 is
selected as N1's GCKS. The GCKS and group members are located in the
same network, and share a GSA that is used only on that network. (If
a group member is attached to multiple networks, then it will install
a unique GSA for each network.) The GCKS may deliver either a single
SA used by each group member (a "many to many" SA) or deliver an
individual SA used by a unique sender (several "one to many" SAs).
GSA messages can be distributed from GCKS to group members within one
hop. Group members can download the GSA from their GCKS before they
establish their routes. It means no routes need to be pre-available
Liu, et. al. Expires January 7, 2008 [Page 7]
Internet-Draft OSPFv3 Automated Group Keying Reqs July 2007
before the OSPFv3 router members run the GKM protocol to download GSA
from their GCKS. This solution can solve the contradiction mentioned
above. It applies to both small and large ASs.
Requirements introduced by this solution are illustrated as follows.
4.1.1. Single Point of GCKS Failure
This is a requirement common to all client/server
protocols/applications. The GCKS MAY be out of service because of
attacks, accidents, reboots, etc. Measures MUST be prepared to
provide continuous keying service in case of single point of GCKS
failure.
4.1.2. GCKS Selecting/Switchover Issue
To deal with the problem of single point of GCKS failure, at least 2
GCKSs need to be deployed in each multicast network. If GCKSs are
acted by the routers, switchover mechanisms are necessary to the GKM
protocol to provide continuous keying service when the running GCKS
becomes out of service and its service needs to be transferred to the
backup GCKS.
Another requirement is GCKS selecting mechanism, which is very like
OSPF DR/BDR selecting mechanism. It is necessary in the case of a
logical GCKS. Routers MUST be able to select their master/backup GCKS
when they start up.
4.1.3. Authorization and Authentication of GCKS
When routers begin to select their GCKS and backup GCKS, they need to
authenticate the candidates and verify that the selected GCKSs are
authorized to act as the GCKSs in the group. Both steps are necessary
in order to ensure that attackers can not become the GCKS by cheating
others. Both authentication and authorization MUST be enforced during
a GCKS selecting process.
4.1.4. New Joiner Issue
New router may join an existing network. It should be able to
automatically discover the local GCKS and contact it to get current
GSA so it can securely perform OSPF SS process with its neighbors.
However, dynamic changes of group membership may not be pre-known.
Thus, the list of authorized routers may not be pre-installed on each
GCKS. GCKS must be able to deal with such dynamic changes of
authorizations. If a new router registers with it, GCKS MUST be able
Liu, et. al. Expires January 7, 2008 [Page 8]
Internet-Draft OSPFv3 Automated Group Keying Reqs July 2007
to authenticate the new one and verify whether it is authorized to
access the GSA even if the new router is not in the GCKS's authorized
routers list.
4.2. Decentralized KSs, Centralized GC
In this solution, KS and GC are separate roles. KS is logical and is
deployed per network; while GC is centrally deployed. This solution
allows for a centralized group management, but allows the KSs to act
autonomously. The GC is responsible for defining the group policy and
authorization, and pushing them to each KS. Each key server then
distributes a GSA conforming to the group policy. As in the
Decentralized GCKS case, each key server distributes a GSA that is
used only on a single network and SAs may be either have a scope of
"many to many" or "one to many".
Requirements in section 4.1.1 and 4.1.2 apply. New requirements
introduced by this solution are illustrated as follows.
4.2.1. Bootstrapping Issue
When the network originally starts up, there are no routes, and
candidate KS/backup KS routers do not have the authorization
information of group membership. After the KS/backup KS are selected,
they will not be able to provide the keying service because they
don't know the information of authorization and authentication of
routers. Measure MUST be provided to handle such issue.
4.2.2. New Joiner Issue
GC is responsible for determining list of authorized routers.
Measures must be provided to keep authorization information in
synchronization between GC and KS. For example, if a new router is
authorized by GC to join the network, KS must be able to authenticate
it and verify it is an authorized one even if it does not know the
new router and cannot contact with the GC.
4.2.3. Authorization and Authentication of KS
When routers begin to select their master/backup KSs, they must be
able to authenticate the candidates and verify that the selected KSs
are authorized to play such roles. Both steps of authentication and
authorization check are necessary in order to ensure that attackers
can not become the KS by cheating others. Both authentication and
authorization MUST be enforced during a KS selecting process.
Liu, et. al. Expires January 7, 2008 [Page 9]
Internet-Draft OSPFv3 Automated Group Keying Reqs July 2007
4.3. Decentralized Delegates, Centralized GCKS
In this solution, there is a delegate in each OSPFv3 multicast
network. GSA messages are created by the centralized GCKS which may
serve multiple OSPFv3 networks at the same time. A delegate is
responsible for receiving GSA messages from the GCKS and re-
distributing them to its local group members. A delegate can be
either physical or logical.
Requirements introduced by this solution are as follows.
4.3.1. Bootstrapping Issue
When neighboring routers initially start, e.g., routers attached to
N1, they have no routes to the key server and so, can not download
the GSA from the centralized GCKS. Security measures MUST be provided
to protect the initial communications among OSPFv3 routers before
their adjacencies are established and routes are calculated out.
4.3.2. New Joiner Issue
When a new router joins, it will perform OSPF SS process with its
neighbors, and then calculate its routes. Before routes are
calculated out, the new coming router cannot contact the remote GCKS
to get current GSA. Measures MUST be provided to let the new joining
router get current GSA from GCKS so that it can securely communicate
with its neighboring routers.
Another problem is that routers may reboot singly. A rebooting router
needs to re-join the network after it restarts. However, during the
rebooting process, GSA may be updated by the GCKS and distributed to
other running routers. Therefore, after a router restarts and resumes
the GSA from its storage (e.g., flash), it may find its local GSA is
out of synchronization with its neighbors and thus, cannot establish
relationship with neighboring routers before it gets the latest GSA.
Measures must be provided to let rebooting routers make sure whether
its local GSA is out of synchronization with its neighbors and, if
yes, be able to get the updated GSA to keep its GSA in
synchronization with its neighbors.
4.3.3. Single Point of Delegate Failure
The delegate may crash or reboot. In such cases, the GSA
redistribution service will be not available. Measures MUST be
prepared to assure continuous GSA relaying service.
Liu, et. al. Expires January 7, 2008 [Page 10]
Internet-Draft OSPFv3 Automated Group Keying Reqs July 2007
4.3.4. Delegate Selecting/Switchover Issue
To deal with the single point of delegate failure, at least 2
delegates must be deployed on every network. In the case of logical
delegates, delegate selecting mechanism is required for the GKM
protocols so routers can autonomously elect their local master/backup
delegates of their local network.
Switchover mechanism is needed to ensure that the backup delegate can
immediately supersede the master delegate in case that the later one
is out of service.
4.3.5. Authorization and Authentication of Delegate
In the delegates selecting process, routers need to authenticate the
candidates and verify that the selected delegates are authorized to
play such roles. Both steps of authenticating and authorization
checking are necessary in order to ensure that an attacker can not
become the delegate by cheating others.
5. Security Considerations
This document lists requirements for automated group keying of OSPFv3.
Several possible solutions and their specific requirements are
discussed. This section will discuss the security risk of the
mentioned solutions.
5.1. Decentralized GCKS
TBD
5.2. Decentralized KS, Centralized GC
TBD
5.3. Decentralized Delegate, Centralized GCKS
TBD
6. IANA Considerations
This document has no IANA considerations.
Liu, et. al. Expires January 7, 2008 [Page 11]
Internet-Draft OSPFv3 Automated Group Keying Reqs July 2007
7. Acknowledgments
Thank Zengjie Kou, Jinliang Feng and Zhenhai Li for technical
discussions.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D. and Overell, P. (Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
[RFC2740] Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", RFC
2740, December 1999.
[RFC3547] Baugher, M., Weis, B., Hardjono, T. and H. Harney, "The
Group Domain of Interpretation", RFC3547, July 2003.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC3740, March 2004.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC3830,
August 2004.
[RFC4046] Baugher, M., Canetti, R., Dondeti, L. and F. Lindholm,
"Multicast Security (MSEC) Group Key Management
Architecture", RFC4046, April 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC4301, December 2005.
[RFC4535] Harney, H., Meth, U., Colegrove, A. and G. Gross, "GSAKMP:
Group Secure Association Key Management Protocol", RFC4535,
June 2006.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for
OSPFv3", RFC4552, June 2006.
[RFC4593] Barbir, A. and Murphy, S. and Y. Yang, "Generic Threats to
Routing Protocols", RFC4593, October 2006.
Liu, et. al. Expires January 7, 2008 [Page 12]
Internet-Draft OSPFv3 Automated Group Keying Reqs July 2007
8.2. Informative References
[GKDP] Dondeti, L., Xiang, J. and S. Rowles, "GKDP: Group Key
Distribution Protocol", work in progress, October 2006.
[I-D: draft-ietf-msec-ipsec-extensions] Weis, B., Gross, G. and D.
Ignjatic, "Multicast Extensions to the Security
Architecture for the Internet Protocol", work in progress,
October 2006.
[CLIQUES] Steiner, M., Tsudik, G. and M. Waidner, "CLIQUES: A New
Approach to Group key Agreement", IEEE ICDCS'98 , MAY 1998.
Liu, et. al. Expires January 7, 2008 [Page 13]
Internet-Draft OSPFv3 Automated Group Keying Reqs July 2007
Author's Addresses
Ya Liu
Huawei Technologies
Kuike Bld., No.9 Xinxi Rd., Shang-Di Information Industry Base
Hai-Dian District, Beijing 100086
P.R. China
Phone: 8610-82836072
Email: liuya@huawei.com
Russ White
Cisco Systems
7025 Kit Creek Road
RTP, NC 27709
USA
Email: riw@cisco.com
Brian Weis
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134-1706
USA
Phone: +1-408-526-4796
Email: bew@cisco.com
Michael Barnes
Cisco, Inc.
170 W. Tasman Drive
San Jose, CA 95134
USA
Phone: +1-408-525-2785
Email: mjbarnes@cisco.com
Liu, et. al. Expires January 7, 2008 [Page 14]
Internet-Draft OSPFv3 Automated Group Keying Reqs July 2007
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that MAY cover technology that MAY be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Liu, et. al. Expires January 7, 2008 [Page 15]