draft-ietf-tsvwg-rsvp-security-groupkeying-06.txt   draft-ietf-tsvwg-rsvp-security-groupkeying-07.txt 
Network Working Group M. Behringer Network Working Group M. Behringer
Internet-Draft F. Le Faucheur Internet-Draft F. Le Faucheur
Intended status: Informational B. Weis Intended status: Informational B. Weis
Expires: December 27, 2010 Cisco Systems Expires: March 27, 2011 Cisco Systems
June 25, 2010 September 23, 2010
Applicability of Keying Methods for RSVP Security Applicability of Keying Methods for RSVP Security
draft-ietf-tsvwg-rsvp-security-groupkeying-06.txt draft-ietf-tsvwg-rsvp-security-groupkeying-07.txt
Abstract Abstract
The Resource reSerVation Protocol (RSVP) allows hop-by-hop integrity The Resource reSerVation Protocol (RSVP) allows hop-by-hop integrity
protection of RSVP neighbors. This requires messages to be protection of RSVP neighbors. This requires messages to be
cryptographically protected using a shared secret between cryptographically protected using a shared secret between
participating nodes. This document compares group keying for RSVP participating nodes. This document compares group keying for RSVP
with per neighbor or per interface keying, and discusses the with per neighbor or per interface keying, and discusses the
associated key provisioning methods as well as applicability and associated key provisioning methods as well as applicability and
limitations of these approaches. The document also discusses limitations of these approaches. The document also discusses
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 27, 2010. This Internet-Draft will expire on March 27, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
4.2.1. Per Neighbor and Per Interface Key Negotiation . . . . 8 4.2.1. Per Neighbor and Per Interface Key Negotiation . . . . 8
4.2.2. Dynamic Group Key Distribution . . . . . . . . . . . . 9 4.2.2. Dynamic Group Key Distribution . . . . . . . . . . . . 9
5. Specific Cases Supporting Use of Group Keying . . . . . . . . 9 5. Specific Cases Supporting Use of Group Keying . . . . . . . . 9
5.1. RSVP Notify Messages . . . . . . . . . . . . . . . . . . . 9 5.1. RSVP Notify Messages . . . . . . . . . . . . . . . . . . . 9
5.2. RSVP-TE and GMPLS . . . . . . . . . . . . . . . . . . . . 9 5.2. RSVP-TE and GMPLS . . . . . . . . . . . . . . . . . . . . 9
6. Applicability of IPsec for RSVP . . . . . . . . . . . . . . . 10 6. Applicability of IPsec for RSVP . . . . . . . . . . . . . . . 10
6.1. General Considerations Using IPsec . . . . . . . . . . . . 10 6.1. General Considerations Using IPsec . . . . . . . . . . . . 10
6.2. Comparing AH and the INTEGRITY Object . . . . . . . . . . 11 6.2. Comparing AH and the INTEGRITY Object . . . . . . . . . . 11
6.3. Applicability of Tunnel Mode . . . . . . . . . . . . . . . 12 6.3. Applicability of Tunnel Mode . . . . . . . . . . . . . . . 12
6.4. Non-Applicability of Transport Mode . . . . . . . . . . . 12 6.4. Non-Applicability of Transport Mode . . . . . . . . . . . 12
6.5. Applicability of Tunnel Mode with Address Preservation . . 12 6.5. Applicability of Tunnel Mode with Address Preservation . . 13
7. End Host Considerations . . . . . . . . . . . . . . . . . . . 13 7. End Host Considerations . . . . . . . . . . . . . . . . . . . 13
8. Applicability to Other Architectures and Protocols . . . . . . 13 8. Applicability to Other Architectures and Protocols . . . . . . 14
9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10.1. Subverted Nodes . . . . . . . . . . . . . . . . . . . . . 15 10.1. Subverted Nodes . . . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
12. Changes to Previous Version . . . . . . . . . . . . . . . . . 16 12. Changes to Previous Version . . . . . . . . . . . . . . . . . 16
12.1. changes from behringer-00 to behringer-01 . . . . . . . . 16 12.1. changes from behringer-00 to behringer-01 . . . . . . . . 17
12.2. changes from behringer-01 to ietf-00 . . . . . . . . . . . 17 12.2. changes from behringer-01 to ietf-00 . . . . . . . . . . . 17
12.3. changes from ietf-00 to ietf-01 . . . . . . . . . . . . . 17 12.3. changes from ietf-00 to ietf-01 . . . . . . . . . . . . . 17
12.4. changes from ietf-01 to ietf-02 . . . . . . . . . . . . . 17 12.4. changes from ietf-01 to ietf-02 . . . . . . . . . . . . . 17
12.5. changes from ietf-02 to ietf-03 . . . . . . . . . . . . . 17 12.5. changes from ietf-02 to ietf-03 . . . . . . . . . . . . . 17
12.6. changes from ietf-03 to ietf-04 . . . . . . . . . . . . . 17 12.6. changes from ietf-03 to ietf-04 . . . . . . . . . . . . . 18
12.7. changes from ietf-04 to ietf-05 . . . . . . . . . . . . . 17 12.7. changes from ietf-04 to ietf-05 . . . . . . . . . . . . . 18
12.8. changes from ietf-05 to ietf-06 . . . . . . . . . . . . . 18 12.8. changes from ietf-05 to ietf-06 . . . . . . . . . . . . . 18
13. Informative References . . . . . . . . . . . . . . . . . . . . 18 12.9. changes from ietf-06 to ietf-07 . . . . . . . . . . . . . 18
13. Informative References . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction and Problem Statement 1. Introduction and Problem Statement
The Resource reSerVation Protocol [RFC2205] allows hop-by-hop The Resource reSerVation Protocol [RFC2205] allows hop-by-hop
authentication of RSVP neighbors, as specified in [RFC2747]. In this authentication of RSVP neighbors, as specified in [RFC2747]. In this
mode, an integrity object is attached to each RSVP message to mode, an integrity object is attached to each RSVP message to
transmit a keyed message digest. This message digest allows the transmit a keyed message digest. This message digest allows the
recipient to verify the identity of the RSVP node that sent the recipient to verify the identity of the RSVP node that sent the
message, and to validate the integrity of the message. Through the message, and to validate the integrity of the message. Through the
skipping to change at page 4, line 9 skipping to change at page 4, line 9
shared key or certificate. This is also the model used for RSVP. shared key or certificate. This is also the model used for RSVP.
Trust in this model is transitive. Each RSVP node trusts explicitly Trust in this model is transitive. Each RSVP node trusts explicitly
only its RSVP next hop peers, through the message digest contained in only its RSVP next hop peers, through the message digest contained in
the INTEGRITY object. The next hop RSVP speaker in turn trusts its the INTEGRITY object. The next hop RSVP speaker in turn trusts its
own peers and so on. See also the document "RSVP security own peers and so on. See also the document "RSVP security
properties" [RFC4230] for more background. properties" [RFC4230] for more background.
The keys used for protecting RSVP messages can, in particular, be The keys used for protecting RSVP messages can, in particular, be
group keys (for example distributed via GDOI [RFC3547], as discussed group keys (for example distributed via GDOI [RFC3547], as discussed
in [I-D.weis-gdoi-mac-tek]). If a group key is used, the in [I-D.weis-gdoi-mac-tek]). If a group key is used, the
authentication granularity becomes group membership, not (individual) authentication granularity becomes group membership of devices, not
peer authentication. (individual) peer authentication between devices.
The trust an RSVP node has to another RSVP node has an explicit and The trust an RSVP node has to another RSVP node has an explicit and
an implicit component. Explicitly the node trusts the other node to an implicit component. Explicitly the node trusts the other node to
maintain the RSVP messages intact or confidential, depending on maintain the RSVP messages intact or confidential, depending on
whether authentication or encryption (or both) are used. This means whether authentication or encryption (or both) is used. This means
only that the message has not been altered or seen by another, non- only that the message has not been altered or seen by another, non-
trusted node. Implicitly each node trusts each other node with which trusted node. Implicitly each node trusts each other node with which
it has a trust relationship established via the mechanisms here to it has a trust relationship established via the mechanisms here to
adhere to the protocol specifications laid out by the various adhere to the protocol specifications laid out by the various
standards. Note that in any group keying scheme like GDOI a node standards. Note that in any group keying scheme like GDOI a node
trusts all the other members of the group (because the authentication trusts all the other members of the group (because the authentication
is now based on group membership, as noted above). is now based on group membership, as noted above).
The RSVP protocol can operate in the presence of a non-RSVP router in The RSVP protocol can operate in the presence of a non-RSVP router in
the path from the sender to the receiver. The non-RSVP hop will the path from the sender to the receiver. The non-RSVP hop will
skipping to change at page 6, line 25 skipping to change at page 6, line 25
belong to the same security domain. belong to the same security domain.
These key types can also be used between security domains, since they These key types can also be used between security domains, since they
are specific to a particular interface or neighbor. Again, interface are specific to a particular interface or neighbor. Again, interface
level keys can be deployed safely only when all the reachable level keys can be deployed safely only when all the reachable
neighbors on the interface belong to the same security domain. neighbors on the interface belong to the same security domain.
Both monotonically increasing sequence number (e.g., the INTEGRITY Both monotonically increasing sequence number (e.g., the INTEGRITY
object simple sequence numbers [RFC2747], or the ESP and AH anti- object simple sequence numbers [RFC2747], or the ESP and AH anti-
replay service [RFC4301] sequence numbers) and time based anti-replay replay service [RFC4301] sequence numbers) and time based anti-replay
methods (e.g., the INTEGITY sequence numbers based on a clock methods (e.g., the INTEGRITY sequence numbers based on a clock
[RFC2747]) can be used with per neighbor and per interface keys. [RFC2747]) can be used with per neighbor and per interface keys.
As discussed in the previous section, per neighbor and per interface As discussed in the previous section, per neighbor and per interface
keys can not be used in the presence of non-RSVP hops. keys can not be used in the presence of non-RSVP hops.
3.2. Group keys 3.2. Group keys
In the case of group keys, all members of a group of RSVP nodes share In the case of group keys, all members of a group of RSVP nodes share
the same key. This implies that a node uses the same key regardless the same key. This implies that a node uses the same key regardless
of the next RSVP hop that will process the message (within the group of the next RSVP hop that will process the message (within the group
skipping to change at page 8, line 11 skipping to change at page 8, line 11
peers, monotonically increasing sequence number methods are not peers, monotonically increasing sequence number methods are not
appropriate. Time based anti-replay methods (e.g., the INTEGITY appropriate. Time based anti-replay methods (e.g., the INTEGITY
sequence numbers based on a clock [RFC2747]) can be used with group sequence numbers based on a clock [RFC2747]) can be used with group
keys. keys.
4. Key Provisioning Methods for RSVP 4. Key Provisioning Methods for RSVP
4.1. Static Key Provisioning 4.1. Static Key Provisioning
Static keys are preconfigured, either manually, or through a network Static keys are preconfigured, either manually, or through a network
management system, and not negotiated via a protocol. The simplest management system. The simplest way to implement RSVP authentication
way to implement RSVP authentication is to use static keys. Static is to use static keys. Static keying can be used with per interface
keying can be used with per interface keys, per neighbor keys or keys, per neighbor keys or group keys.
group keys.
The provisioning of static keys requires either manual operator The provisioning of static keys requires either manual operator
intervention on each node, or a network management system performing intervention on each node, or a network management system performing
the same task. Time synchronization of static key provisioning and the same task. Time synchronization of static key provisioning and
changes is critical, to avoid inconsistent keys within a security changes is critical, to avoid inconsistent keys within a security
domain. domain.
Static key provisioning is therefore not an ideal model in a large Static key provisioning is therefore not an ideal model in a large
network. network.
skipping to change at page 12, line 11 skipping to change at page 12, line 11
the security associations in both cases, AH and INTEGRITY object, are the security associations in both cases, AH and INTEGRITY object, are
between the same RSVP neighbors. From a keying point of view both between the same RSVP neighbors. From a keying point of view both
approaches are therefore comparable. approaches are therefore comparable.
6.3. Applicability of Tunnel Mode 6.3. Applicability of Tunnel Mode
IPsec tunnel mode encapsulates the original packet, prepending a new IPsec tunnel mode encapsulates the original packet, prepending a new
IP header plus an ESP or AH sub-header. The entire original packet IP header plus an ESP or AH sub-header. The entire original packet
plus the ESP/AH sub-header is secured. In the case of ESP the new, plus the ESP/AH sub-header is secured. In the case of ESP the new,
outer IP header however is not cryptographically secured in this outer IP header however is not cryptographically secured in this
process. This has consequences when group keying is used; see the process.
Security Considerations section for details.
Protecting RSVP packets with IPsec tunnel mode works with any of the Protecting RSVP packets with IPsec tunnel mode works with any of the
above described keying methods (interface, neighbor or group based), above described keying methods (interface, neighbor or group based),
as long as there are no non-RSVP nodes on the path. Note that for as long as there are no non-RSVP nodes on the path (however, see
RSVP messages to be visible and considered at each hop, such a tunnel group keying considerations below). Note that for RSVP messages to
would not cross routers, but each RSVP node would establish a tunnel be visible and considered at each hop, such a tunnel would not cross
with each of its peers, effectively leading to link protection. routers, but each RSVP node would establish a tunnel with each of its
peers, effectively leading to link protection.
In the presence of a non-RSVP hop, tunnel mode cannot be applied, In the presence of a non-RSVP hop, tunnel mode cannot be applied,
because a router upstream from a non-RSVP hop does not know the next because a router upstream from a non-RSVP hop does not know the next
RSVP hop, and can thus not apply the correct tunnel header. This is RSVP hop, and can thus not apply the correct tunnel header. This is
independent of the key type used. independent of the key type used.
The use of group keying with ESP tunnel mode where a security gateway
places a peer security gateway address as the destination of the ESP
packet has consequences. In particular, if a man-in-the-middle
attacker re-directs the ESP-protected reservation to a different
security gateway, the receiving security gateway cannot detect that
the destination address was changed. However, it has received and
will act upon or route a RSVP reservation that will be be routed
along an unintended path. Because RSVP routers encountering the RSVP
packet path will not be aware that this is an unintended path, they
will act upon it and the resulting RSVP state along both the intended
path and unintended path will both be incorrect. Therefore group
keying should not be used with ESP tunnel mode except with address
preservation (see Section 6.5).
6.4. Non-Applicability of Transport Mode 6.4. Non-Applicability of Transport Mode
IPsec transport mode, as defined in [RFC4303] is not suitable for IPsec transport mode, as defined in [RFC4303] is not suitable for
securing RSVP Path messages, since those messages preserve the securing RSVP Path messages, since those messages preserve the
original source and destination. [RFC4303] states explicitly that original source and destination. [RFC4303] states explicitly that
"the use of transport mode by an intermediate system (e.g., a "the use of transport mode by an intermediate system (e.g., a
security gateway) is permitted only when applied to packets whose security gateway) is permitted only when applied to packets whose
source address (for outbound packets) or destination address (for source address (for outbound packets) or destination address (for
inbound packets) is an address belonging to the intermediate system inbound packets) is an address belonging to the intermediate system
itself." This would not be the case for RSVP Path messages. itself." This would not be the case for RSVP Path messages.
6.5. Applicability of Tunnel Mode with Address Preservation 6.5. Applicability of Tunnel Mode with Address Preservation
When the identity of the next-hop RSVP peer is not known, it is not When the identity of the next-hop RSVP peer is not known, it is not
possible to use tunnel-endpoint destination address in the Tunnel possible to use a tunnel-endpoint destination address in the Tunnel
Mode outer IP header. The document "Multicast Extensions to the Mode outer IP header. The document "Multicast Extensions to the
Security Architecture for the Internet Protocol" [RFC5374] defines in Security Architecture for the Internet Protocol" [RFC5374] defines in
section 3.1 a new tunnel mode: Tunnel mode with address preservation. section 3.1 a new tunnel mode: Tunnel mode with address preservation.
This mode copies the destination and optionally the source address This mode copies the destination and optionally the source address
from the inner header to the outer header. Therefore the from the inner header to the outer header. Therefore the
encapsulated packet will have the same destination address as the encapsulated packet will have the same destination address as the
original packet, and be normally subject to the same routing original packet, and be normally subject to the same routing
decisions. While [RFC5374] is focusing on multicast environments, decisions. While [RFC5374] is focusing on multicast environments,
tunnel mode with address preservation can be used also to protect tunnel mode with address preservation can be used also to protect
unicast traffic in conjunction with group keying. Note that in this unicast traffic in conjunction with group keying. Note that in this
skipping to change at page 13, line 14 skipping to change at page 13, line 31
outer tunnel mode IP header. This addressing scheme is used by RSVP outer tunnel mode IP header. This addressing scheme is used by RSVP
to ensure that the packets continue along the routed path toward the to ensure that the packets continue along the routed path toward the
destination end host. destination end host.
Tunnel mode with address preservation, in conjunction with group Tunnel mode with address preservation, in conjunction with group
keying, allows the use of AH or ESP for protection of RSVP even in keying, allows the use of AH or ESP for protection of RSVP even in
cases where non-RSVP nodes have to be traversed. This is because it cases where non-RSVP nodes have to be traversed. This is because it
allows routing of the IPsec protected packet through the non-RSVP allows routing of the IPsec protected packet through the non-RSVP
nodes in the same way as if it was not IPsec protected. nodes in the same way as if it was not IPsec protected.
When used with group keying, tunnel mode with address preservation
can be used to mitigate re-direction attacks where a man-in-the-
middle modifies the destination of the outer IP header of the tunnel
mode packet. The inbound processing rules for tunnel mode with
address preservation (Section 5.2 of [RFC5374]) require that the
receiver verify that the addresses in the outer IP header and the
inner IP header are consistent. Therefore, the attack should be
detected and RSVP reservations will not proceed along an unintended
path.
7. End Host Considerations 7. End Host Considerations
Unless RSVP Proxy entities ([I-D.ietf-tsvwg-rsvp-proxy-approaches] Unless RSVP Proxy entities ([I-D.ietf-tsvwg-rsvp-proxy-approaches]
are used, RSVP signaling is controlled by end systems and not are used, RSVP signaling is controlled by end systems and not
routers. As discussed in [RFC4230], RSVP allows both user-based routers. As discussed in [RFC4230], RSVP allows both user-based
security and host-based security. User-based authentication aims at security and host-based security. User-based authentication aims at
"providing policy based admission control mechanism based on user "providing policy based admission control mechanism based on user
identities or application." To identify the user or the application, identities or application." To identify the user or the application,
a policy element called AUTH_DATA, which is contained in the a policy element called AUTH_DATA, which is contained in the
POLICY_DATA object, is created by the RSVP daemon at the user's host POLICY_DATA object, is created by the RSVP daemon at the user's host
skipping to change at page 18, line 30 skipping to change at page 18, line 43
presence of non-RSVP hops. presence of non-RSVP hops.
o Cleared up inconsistent wording on "trust group" and "security o Cleared up inconsistent wording on "trust group" and "security
domain", and defined the latter. (Section 3) domain", and defined the latter. (Section 3)
o Added a paragraph on the applicability of sequence numbers in o Added a paragraph on the applicability of sequence numbers in
section 3.1 and 3.2. section 3.1 and 3.2.
o Defined static key provisioning. (Section 4.1) o Defined static key provisioning. (Section 4.1)
o Clarified wording in 6.1 on the use of GDOI. o Clarified wording in 6.1 on the use of GDOI.
o Added in section 6.6 some clarification to the use of tunnel mode o Added in section 6.6 some clarification to the use of tunnel mode
with address preservation. with address preservation.
12.9. changes from ietf-06 to ietf-07
This version addressed the last WGLC, and incorporates a few comments
from Bob Briscoe, mostly editorial. The main change is the re-
insertion of a potential man-in-the-middle attack with group keying,
which was accidentally deleted. Affected sections are 6.3 and 6.5.
13. Informative References 13. Informative References
[I-D.ietf-pcn-architecture] [I-D.ietf-pcn-architecture]
Eardley, P., "Pre-Congestion Notification (PCN) Eardley, P., "Pre-Congestion Notification (PCN)
Architecture", draft-ietf-pcn-architecture-11 (work in Architecture", draft-ietf-pcn-architecture-11 (work in
progress), April 2009. progress), April 2009.
[I-D.ietf-tsvwg-rsvp-proxy-approaches] [I-D.ietf-tsvwg-rsvp-proxy-approaches]
Faucheur, F., Manner, J., Wing, D., and L. Faucheur, "RSVP Faucheur, F., Manner, J., Wing, D., and L. Faucheur, "RSVP
Proxy Approaches", Proxy Approaches",
draft-ietf-tsvwg-rsvp-proxy-approaches-09 (work in draft-ietf-tsvwg-rsvp-proxy-approaches-09 (work in
progress), March 2010. progress), March 2010.
[I-D.weis-gdoi-mac-tek] [I-D.weis-gdoi-mac-tek]
Weis, B. and S. Rowles, "GDOI Generic Message Weis, B. and S. Rowles, "GDOI Generic Message
Authentication Code Policy", draft-weis-gdoi-mac-tek-00 Authentication Code Policy", draft-weis-gdoi-mac-tek-01
(work in progress), July 2008. (work in progress), June 2010.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000. Authentication", RFC 2747, January 2000.
 End of changes. 19 change blocks. 
30 lines changed or deleted 61 lines changed or added

This html diff was produced by rfcdiff 1.39. The latest version is available from http://tools.ietf.org/tools/rfcdiff/