MSEC Working Group B. Weis
Internet-Draft Cisco Systems
Intended status: Standards Track June 21, 2007
Expires: December 23, 2007
Group Domain of Interpretation (GDOI) support for RSVP
draft-weis-gdoi-for-rsvp-00
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.
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 December 23, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Weis Expires December 23, 2007 [Page 1]
Internet-Draft GDOI-RSVP June 2007
Abstract
This memo describes the policy required for the Group Domain of
Interpretation (GDOI) [RFC3547] group key management system to
distribute security policy for RSVP.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
2. GDOI Operations . . . . . . . . . . . . . . . . . . . . . . . 5
3. SA TEK payload for RSVP . . . . . . . . . . . . . . . . . . . 6
3.1. MAC Algorithm . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Sequence Number Types . . . . . . . . . . . . . . . . . . 7
3.3. Optional Attributes . . . . . . . . . . . . . . . . . . . 7
4. Key Packet definition for RSVP . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Weis Expires December 23, 2007 [Page 2]
Internet-Draft GDOI-RSVP June 2007
1. Introduction
The Group Domain of Interpretation (GDOI) is a group key management
protocol fitting into the Multicast Security Group Key Management
Architecture . GDOI is used to disseminate group security policy and
keying material to group members for use with a particular
cryptographic system.
The RSVP protocol provides a means for establishing resource
reservations between cooperating systems. To ensure the integrity of
the associated reservation and admission control mechanisms, the RSVP
Authentication mechanisms defined in [RFC2747] and [RFC3097] may be
used. These protect RSVP message integrity hop-by-hop and provide
node authentication as well as replay protection, thereby protecting
against corruption and spoofing of RSVP messages.
[RFC2747] discusses several approaches for key distribution. First,
the RSVP Authentication shared keys can be distributed manually.
This is the base option and its support is mandated for any
implementation. However, in some environments, this approach may
become a burden if keys frequently change over time. Alternatively,
a standard key management protocol for secure shared key distribution
can be used. However, existing shared key distribution protocols may
not be appropriate in all environments because of the complexity or
operational burden they involve. In effect, this impedes the
practical use of RSVP Authentication.
Another issue with RSVP Authentication is that shared key cannot be
used among RSVP routers when those are interconnected via routers
that do not run RSVP. This is because, in this situation, an RSVP
router does not always know the RSVP next hop for an RSVP message at
the time of forwarding it.
Such limitations with the current RSVP security mechanisms are
further discussed in [I-D.behringer-tsvwg-rsvp-security-groupkeying].
Since RSVP nodes effectively acts as a group of cooperating systems,
they can benefit from sharing the same keying material.
[I-D.behringer-tsvwg-rsvp-security-groupkeying] presents a framework
for RSVP security using dynamic group keying and discusses its
applicability. In line with this framework, the present document
describes extension to GDOI for distribution of security policy and
keying material for RSVP.
1.1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Weis Expires December 23, 2007 [Page 3]
Internet-Draft GDOI-RSVP June 2007
document are to be interpreted as described in [RFC2119].
Weis Expires December 23, 2007 [Page 4]
Internet-Draft GDOI-RSVP June 2007
2. GDOI Operations
The GDOI group key management protocol [RFC3547]) actively manages
keys for a set of group members. In the case of RSVP, the set of
group members belonging to a single group are routers and/or hosts
that are trusted to establish reservations for a set of applications,
and also trust the other group members to act appropriately within
the group (e.g., not to spoof other group members). A given group
need not include all of the RSVP nodes passing a reservation. For
example, the group may be comprised of routers in a single ISP, where
the RSVP packets are protected using a different model between ISPs.
Similarly, different groups may be used for different sets of RSVP
nodes. Whether or not the group key is used and which RSVP nodes
belong to a given group should depend on the trust model between the
co-operating systems.
GDOI begins operation when group members "register" to a GDOI key
server using the GDOI GROUPKEY_PULL protocol. The key server first
authenticates and authorizes each group member. GDOI also derives
encryption keys shrared privately between the key server and the
group member. These keys are used to protect the group policy and
keying material as it is distributed to the group member. In the
case of RSVP, the group policy consists of policy and keying material
intended for use with the [RFC2747] [RFC3097] INTEGRITY Option.
The GDOI key server also distributes policy and keys that describe
how it will distribute updates to group policy in a "rekey" message,
also known as the GDOI GROUPKEY_PUSH message. Rekey messages are
typically distributed as IP multicast packets. They provide
replacement RSVP policy and keying material (e.g., when RSVP keys
expire) or to remove (i.e., revoke) group members in a non-disruptive
manner.
Both the GDOI registration and GDOI rekey protocols distribute
cryptosystem policy in an SA TEK payload. Each SA TEK payload
describes a particular type of cryptographic system policy, and this
memo describes a new type for the RSVP INTEGRITY Option. Keying
material is distributed in KD payload Key Packets. This memo
describes how those keys are distributed for the RSVP INTEGRITY
Option.
Weis Expires December 23, 2007 [Page 5]
Internet-Draft GDOI-RSVP June 2007
3. SA TEK payload for RSVP
RFC 2747 describes a number of policy items that make up an RSVP
security association. When a centralized group key management system
such as GDOI is used, the same RSVP policy is distributed to all
group members. The following SA TEK payload distributes 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Key Identifier !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! ! MAC Algorithm ! Seq. Num. Type!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Key Lifetime !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Optional Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
The SA TEK Payload fields are defined as follows:
o Key Identifier (6 octets) -- Value describing the identity of the
key. The group member will use this value as the Key Identifier
in the RFC 2747 INTEGRITY Object. The key identifier will
uniquely define the particular key distributed in the KD payload.
o MAC Algorithm (1 octet) -- Value specifying which Message
Authentication Code (MAC) is used to generate the Keyed Message
Digest field of the RFC 2747 INTEGRITY Object . MAC Algorithm
types are defined below. Values are defined in the IANA
Considerations section.
o Sequence Number Type (1 octet) -- Value specifying how the
sequence number field is constructed. Sequence Number Types are
defined below. Values are defined in the IANA Considerations
section.
o Key Lifetime (4 octets) -- Value specifying the remaining lifetime
of the SA TEK, in seconds. If the KeyStartValid optional
attribute is included in the SA TEK, this lifetime specifies the
entire lifetime of the SA TEK. Otherwise, it represents the
partial remaining lifetime.
o Optional Attributes (Variable) -- Optional TLV attributes, as
defined below.
Weis Expires December 23, 2007 [Page 6]
Internet-Draft GDOI-RSVP June 2007
3.1. MAC Algorithm
The following MAC algorithms are defined for use with this TEK.
o HMAC-MD5. The MD5 algorithm used with an HMAC construction
[RFC2104]. This MAC algorithm is considered weak, but is required
by a conforming RFC 2747 implementation.
o HMAC-SHA1. The SHA1 algorithm used with an HMAC construction
[RFC2104].
3.2. Sequence Number Types
The following methods of constructing sequence numbers is defined for
use with this TEK.
o COUNTER. This corresponds to the Simple Sequence Numbers method
defined in Section 3.1 of RFC 2747. When COUNTER based sequence
numbers are used, each group member maintains its own sequence
number for a given group in order to set the sequence number field
in RSVP messages generated in this group. Therefore, an RSVP
receiver MUST track received sequence numbers separately for each
RSVP neighbour in order to reliably distinguish between new and
replay messages.
o TIME. This corresponds to the Sequence Numbers Based on a Real
Time Clock method described in Section 3.2 of RFC 2747 or the
Sequence Numbers Based on a Network Recovered Clock method
described in Section 3.3 or RFC 2747.
3.3. Optional Attributes
The following attributes may be present in the TEK Payload. The
attributes must follow the format defined in ISAKMP [RFC2408] Section
3.3. In the table, attributes that are defined as TV are marked as
Basic (B); attributes that are defined as TLV are marked as Variable
(V). Values are defined in the IANA Considerations section.
o KeyStartValid (V). This attribute specifies an real time in the
future at which the TEK take effect [RFC2747]. The corresponding
KeyEndValid time is computed by adding the Key Lifetime value to
KeyStartValid. If the valid start time for the SA TEK is in the
past KeyStartValid MUST NOT be distributed as part of the SA TEK.
The KeyStartValid value is represented as the number of seconds
since since 0 hours, 0 minutes, 0 seconds, January 1, 1970.
Weis Expires December 23, 2007 [Page 7]
Internet-Draft GDOI-RSVP June 2007
4. Key Packet definition for RSVP
Keying material for the RSVP INTEGRITY Option is distributed in a Key
Packet as part of the GDOI KD payload. The Key packet is formed as
follows.
o KD Type. The type of KD MUST be TEK.
o SPI. The Key Identifier is placed in the SPI field.
o Key. The keying material for the MAC algorithm is placed in a
TEK_ALGORITHM_KEY attribute.
The Key Packet MUST NOT contain a TEK_ALGORITHM_KEY or
TEK_SOURCE_AUTH_KEY attribute.
Weis Expires December 23, 2007 [Page 8]
Internet-Draft GDOI-RSVP June 2007
5. IANA Considerations
A new GDOI SA TEK type Protocol-ID type [GDOI-REG] should be assigned
from the RESERVED space. The new algorithm id should be called
GDOI_PROTO_RSVP_INTEGRITY, and refers to the INTEGRITY Object defined
in [RFC2747].
Terms describing policies for allocating new name space types below
are defined in [RFC2434].
The following MAC Algorithms are defined as a part of this memo.
MAC Algorithm Type Value
------------------ -----
RESERVED 0
HMAC-MD5 1
HMAC-SHA1 2
Standards Action 3-127
Private Use 128-255
The following Sequence Number Types are defined as a part of this
memo.
Sequence Number Type Value
-------------------- -----
RESERVED 0
COUNTER 1
TIME 2
Standards Action 3-127
Private Use 128-255
The following Optional Attributes are defined as part of this memo.
Optional Attribute Value
------------------ -----
RESERVED 0
KeyStartValid 1
Standards Action 2-127
Private Use 128-255
Weis Expires December 23, 2007 [Page 9]
Internet-Draft GDOI-RSVP June 2007
6. Security Considerations
This memo describes the passing of policy and keying material used by
an RSVP speaker to produce an RFC 2747 INTEGRITY Object. This policy
and keying material is protected by the GDOI protocol described in
[RFC3547]. The security considerations in that memo apply fully to
this memo as well.
Weis Expires December 23, 2007 [Page 10]
Internet-Draft GDOI-RSVP June 2007
7. Acknowledgements
Francois Le Faucheur provided text for the Introduction section
summarizing key distribution issues with RSVP message integrity.
Weis Expires December 23, 2007 [Page 11]
Internet-Draft GDOI-RSVP June 2007
8. References
8.1. Normative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097,
April 2001.
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003.
8.2. Informative References
[GDOI-REG]
Internet Assigned Numbers Authority, "Group Domain of
Interpretation (GDOI) Payload Type Values", IANA Registry,
December 2004,
<http://www.iana.org/assignments/gdoi-payloads>.
[I-D.behringer-tsvwg-rsvp-security-groupkeying]
Behringer, M., Le Faucheur, F., and F. Baker, "A Framework
for RSVP Security Using Dynamic Group Keying", July 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet
Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
Weis Expires December 23, 2007 [Page 12]
Internet-Draft GDOI-RSVP June 2007
Author's Address
Brian Weis
Cisco Systems
170 W. Tasman Drive
San Jose, California 95134-1706
USA
Phone: +1-408-526-4796
Email: bew@cisco.com
Weis Expires December 23, 2007 [Page 13]
Internet-Draft GDOI-RSVP June 2007
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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Weis Expires December 23, 2007 [Page 14]