. In any case,
it is not possible to make a QoS reservation for the entire path.
Two similar examples are remote access using a VPN and protection
of data traffic between a home agent (or a security gateway in
the home network) and a mobile node. The same problem occurs
with a nested application of IPsec (for example, IPsec between A
and SGW and between A and B).
One possible solution to this problem is to change the flow
identifier along the path to capture the new flow identifier
after an IPsec endpoint.
IPsec tunnels that neither start nor terminate at one of the
signaling end points (for example between two networks) should be
addressed differently by recursively applying an RSVP signaling
exchange for the IPsec tunnel. RSVP signaling within tunnels is
addressed in [13].
Tschofenig & Graveman Informational [Page 35]
RFC 4230 RSVP Security Properties December 2005
(3) It is assumed that SPIs do not change during the lifetime of the
established QoS reservation. If a new IPsec SA is created, then
a new SPI is allocated for the security association. To reflect
this change, either a new reservation has to be established or
the flow identifier of the existing reservation has to be
updated. Because IPsec SAs usually have a longer lifetime, this
does not seem to be a major issue. IPsec protection of SCTP data
traffic might more often require an IPsec SA (and SPI) change to
reflect added and removed IP addresses from an SCTP association.
5.5. End-to-End Security Issues and RSVP
End-to-end security for RSVP has not been discussed throughout the
document. In this context, end-to-end security refers to credentials
transmitted between the two end hosts using RSVP. It is obvious that
care must be taken to ensure that routers along the path are able to
process and modify the signaling messages according to prescribed
processing procedures. However, some objects or mechanisms could be
used for end-to-end protection. The main question, however, is the
benefit of such end-to-end security. First, there is the question of
how to establish the required security association. Between two
arbitrary hosts on the Internet, this might turn out to be quite
difficult. Second, the usefulness of end-to-end security depends on
the architecture in which RSVP is deployed. If RSVP is used only to
signal QoS information into the network, and other protocols have to
be executed beforehand to negotiate the parameters and to decide
which entity is charged for the QoS reservation, then no end-to-end
security is likely to be required. Introducing end-to-end security
to RSVP would then cause problems with extensions like RSVP proxy
[37], Localized RSVP [38], and others that terminate RSVP signaling
somewhere along the path without reaching the destination end host.
Such a behavior could then be interpreted as a man-in-the-middle
attack.
5.6. IPsec Protection of RSVP Signaling Messages
It is assumed throughout that RSVP signaling messages can also be
protected by IPsec [3] in a hop-by-hop fashion between two adjacent
RSVP nodes. RSVP, however, uses special processing of signaling
messages, which complicates IPsec protection. As explained in this
section, IPsec should only be used for protection of RSVP signaling
messages in a point-to-point communication environment (i.e., an RSVP
message can only reach one RSVP router and not possibly more than
one). This restriction is caused by the combination of signaling
message delivery and discovery into a single message. Furthermore,
end-to-end addressing complicates IPsec handling considerably. This
section describes at least some of these complications.
Tschofenig & Graveman Informational [Page 36]
RFC 4230 RSVP Security Properties December 2005
RSVP messages are transmitted as raw IP packets with protocol number
46. It might be possible to encapsulate them in UDP as described in
Appendix C of [6]. Some RSVP messages (Path, PathTear, and ResvConf)
must have the Router Alert IP Option set in the IP header. These
messages are addressed to the (unicast or multicast) destination
address and not to the next RSVP node along the path. Hence, an
IPsec traffic selector can only use these fields for IPsec SA
selection. If there is only a single path (and possibly all traffic
along it is protected) then there is no problem for IPsec protection
of signaling messages. This type of protection is not common and
might only be used to secure network access between an end host and
its first-hop router. Because the described RSVP messages are
addressed to the destination address instead of the next RSVP node,
it is not possible to use IPsec ESP [17] or AH [16] in transport
mode--only IPsec in tunnel mode is possible.
If an RSVP message can taket more than one possible path, then the
IPsec engine will experience difficulties protecting the message.
Even if the RSVP daemon installs a traffic selector with the
destination IP address, still, no distinguishing element allows
selection of the correct security association for one of the possible
RSVP nodes along the path. Even if it possible to apply IPsec
protection (in tunnel mode) for RSVP signaling messages by
incorporating some additional information, there is still the
possibility that the tunneled messages do not recognize a path change
in a non-RSVP router. In this case the signaling messages would
simply follow a different path than the data.
RSVP messages like RESV can be protected by IPsec, because they
contain enough information to create IPsec traffic selectors that
allow differentiation between various next RSVP nodes. The traffic
selector would then contain the protocol number and the source and
destination address pair of the two communicating RSVP nodes.
One benefit of using IPsec is the availability of key management
using either IKE [39], KINK [40] or IKEv2 [41].
5.7. Authorization
[34] describes two trust models (NJ Turnpike and NJ Parkway) and two
authorization models (per-session and per-channel financial
settlement). The NJ Turnpike model gives a justification for hop-by-
hop security protection. RSVP focuses on the NJ Turnpike model,
although the different trust models are not described in detail.
RSVP supports the NJ Parkway model and per-channel financial
settlement only to a certain extent. Authentication of the user (or
end host) can be provided with the user identity representation
Tschofenig & Graveman Informational [Page 37]
RFC 4230 RSVP Security Properties December 2005
mechanism, but authentication might, in many cases, be insufficient
for authorization. The communication procedures defined for policy
objects [42] can be improved to support the more efficient per-
channel financial settlement model by avoiding policy handling
between inter-domain networks at a signaling message granularity.
Additional information about expected behavior of policy handling in
RSVP can also be obtained from [43].
[35] and [36] provide additional information on authorization. No
good and agreed mechanism for dealing with authorization of QoS
reservations in roaming environments is provided. Price distribution
mechanisms are only described in papers and never made their way
through standardization. RSVP focuses on receiver-initiated
reservations with authorization for the QoS reservation by the data
receiver, which introduces a fair amount of complexity for mobility
handling as described, for example, in [36].
6. Conclusions
RSVP was the first QoS signaling protocol that provided some security
protection. Whether RSVP provides appropriate security protection
heavily depends on the environment where it is deployed. RSVP as
specified today should be viewed as a building block that has to be
adapted to a given architecture.
This document aims to provide more insight into the security of RSVP.
It cannot be interpreted as a pass or fail evaluation of the security
provided by RSVP.
Certainly this document is not a complete description of all security
issues related to RSVP. Some issues that require further
consideration are RSVP extensions (for example [12]), multicast
issues, and other security properties like traffic analysis.
Additionally, the interaction with mobility protocols (micro- and
macro-mobility) demands further investigation from a security point
of view.
What can be learned from practical protocol experience and from the
increased awareness regarding security is that some of the available
credential types have received more acceptance than others. Kerberos
is a system that is integrated into many IETF protocols today.
Public-key-based authentication techniques are, however, still
considered to be too heavy-weight (computationally and from a
bandwidth perspective) to be used for per-flow signaling. The
increased focus on denial of service attacks puts additional demands
on the design of public-key-based authentication.
Tschofenig & Graveman Informational [Page 38]
RFC 4230 RSVP Security Properties December 2005
The following list briefly summarizes a few security or architectural
issues that deserve improvement:
o Discovery and signaling message delivery should be separated.
o For some applications and scenarios, it cannot be assumed that
neighboring RSVP-aware nodes know each other. Hence, some in-path
discovery mechanism should be provided.
o Addressing for signaling messages should be done in a hop-by-hop
fashion.
o Standard security protocols (IPsec, TLS, or CMS) should be used
whenever possible. Authentication and key exchange should be
separated from signaling message protection. In general, it is
necessary to provide key management to establish security
associations dynamically for signaling message protection.
Relying on manually configured keys between neighboring RSVP nodes
is insufficient. A separate, less frequently executed key
management and security association establishment protocol is a
good place to perform entity authentication, security service
negotiation and selection, and agreement on mechanisms,
transforms, and options.
o The use of public key cryptography in authorization tokens,
identity representations, selective object protection, etc. is
likely to cause fragmentation, the need to protect against denial
of service attacks, and other problems.
o Public key authentication and user identity confidentiality
provided with RSVP require some improvement.
o Public-key-based user authentication only provides entity
authentication. An additional security association is required to
protect signaling messages.
o Data origin authentication should not be provided by non-RSVP
nodes (such as the PDP). Such a procedure could be accomplished
by entity authentication during the authentication and key
exchange phase.
o Authorization and charging should be better integrated into the
base protocol.
o Selective message protection should be provided. A protected
message should be recognizable from a flag in the header.
Tschofenig & Graveman Informational [Page 39]
RFC 4230 RSVP Security Properties December 2005
o Confidentiality protection is missing and should therefore be
added to the protocol. The general principle is that protocol
designers can seldom foresee all of the environments in which
protocols will be run, so they should allow users to select from a
full range of security services, as the needs of different user
communities vary.
o Parameter and mechanism negotiation should be provided.
7. Security Considerations
This document discusses security properties of RSVP and, as such, it
is concerned entirely with security.
8. Acknowledgements
We would like to thank Jorge Cuellar, Robert Hancock, Xiaoming Fu,
Guenther Schaefer, Marc De Vuyst, Bob Grillo, and Jukka Manner for
their comments. Additionally, Hannes would like to thank Robert and
Jorge for their time discussing various issues.
Finally, we would like to thank Allison Mankin and John Loughney for
their guidance and input.
9. References
9.1. Normative References
[1] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000.
[2] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750,
January 2000.
[3] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[4] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[6] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
Tschofenig & Graveman Informational [Page 40]
RFC 4230 RSVP Security Properties December 2005
[7] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
Herzog, S., and R. Hess, "Identity Representation for RSVP",
RFC 3182, October 2001.
[8] Kohl, J. and C. Neuman, "The Kerberos Network Authentication
Service (V5)", RFC 1510, September 1993. Obsoleted by RFC
4120.
[9] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
[10] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A.
Sastry, "The COPS (Common Open Policy Service) Protocol", RFC
2748, January 2000.
[11] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R., and A.
Sastry, "COPS usage for RSVP", RFC 2749, January 2000.
[12] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data
Flows", RFC 2207, September 1997.
[13] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP
Operation Over IP Tunnels", RFC 2746, January 2000.
9.2. Informative References
[14] Hess, R. and S. Herzog, "RSVP Extensions for Policy Control",
Work in Progress, June 2001.
[15] "Secure Hash Standard, NIST, FIPS PUB 180-1", Federal
Information Processing Society, April 1995.
[16] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[17] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[18] Fowler, D., "Definitions of Managed Objects for the DS1, E1,
DS2 and E2 Interface Types", RFC 2495, January 1999.
[19] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
"OpenPGP Message Format", RFC 2440, November 1998.
[20] Hornstein, K. and J. Altman, "Distributing Kerberos KDC and
Realm Information with DNS", Work in Progress, July 2002.
Tschofenig & Graveman Informational [Page 41]
RFC 4230 RSVP Security Properties December 2005
[21] Dobbertin, H., Bosselaers, A., and B. Preneel, "RIPEMD-160: A
strengthened version of RIPEMD in Fast Software Encryption",
LNCS vol. 1039, pp. 71-82, 1996.
[22] Dobbertin, H., "The Status of MD5 After a Recent Attack", RSA
Laboratories CryptoBytes, vol. 2, no. 2, 1996.
[23] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
[24] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000.
[25] "Microsoft Authorization Data Specification v. 1.0 for
Microsoft Windows 2000 Operating Systems", April 2000.
[26] Cable Television Laboratories, Inc., "PacketCable Security
Specification, PKT-SP-SEC-I01-991201", website:
http://www.PacketCable.com/, June 2003.
[27] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams,
"X.509 Internet Public Key Infrastructure Online Certificate
Status Protocol - OCSP", RFC 2560, June 1999.
[28] Malpani, A., Housley, R., and T. Freeman, "Simple Certificate
Validation Protocol (SCVP)", Work in Progress, October 2005.
[29] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369,
August 2002.
[30] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version
1.5", RFC 2315, March 1998.
[31] "Specifications and standard documents", website:
http://www.PacketCable.com/, March 2002.
[32] Davis, D. and D. Geer, "Kerberos With Clocks Adrift: History,
Protocols and Implementation", USENIX Computing Systems, vol 9
no. 1, Winter 1996.
[33] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, February 2005.
[34] Tschofenig, H., Buechli, M., Van den Bosch, S., and H.
Schulzrinne, "NSIS Authentication, Authorization and Accounting
Issues", Work in Progress, March 2003.
Tschofenig & Graveman Informational [Page 42]
RFC 4230 RSVP Security Properties December 2005
[35] Tschofenig, H., Buechli, M., Van den Bosch, S., Schulzrinne,
H., and T. Chen, "QoS NSLP Authorization Issues", Work in
Progress, June 2003.
[36] Thomas, M., "Analysis of Mobile IP and RSVP Interactions", Work
in Progress, October 2002.
[37] Gai, S., Gaitonde, S., Elfassy, N., and Y. Bernet, "RSVP
Proxy", Work in Progress, March 2002.
[38] Manner, J., Suihko, T., Kojo, M., Liljeberg, M., and K.
Raatikainen, "Localized RSVP", Work in Progress, September
2004.
[39] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[40] Thomas, M., "Kerberized Internet Negotiation of Keys (KINK)",
Work in Progress, October 2005.
[41] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, November 2005.
[42] Herzog, S., "Accounting and Access Control in RSVP", PhD
Dissertation, USC, Work in Progress, November 1995.
[43] Herzog, S., "Accounting and Access Control for Multicast
Distributions: Models and Mechanisms", June 1996.
[44] Pato, J., "Using Pre-Authentication to Avoid Password Guessing
Attacks", Open Software Foundation DCE Request for Comments,
December 1992.
[45] Tung, B. and L. Zhu, "Public Key Cryptography for Initial
Authentication in Kerberos", Work in Progress, November 2005.
[46] Wu, T., "A Real-World Analysis of Kerberos Password Security",
in Proceedings of the 1999 Internet Society Network and
Distributed System Security Symposium, San Diego, February
1999.
[47] Wu, T., Wu, F., and F. Gong, "Securing QoS: Threats to RSVP
Messages and Their Countermeasures", IEEE IWQoS, pp. 62-64,
1999.
[48] Talwar, V., Nahrstedt, K., and F. Gong, "Securing RSVP For
Multimedia Applications", Proc ACM Multimedia 2000 (Multimedia
Security Workshop), November 2000.
Tschofenig & Graveman Informational [Page 43]
RFC 4230 RSVP Security Properties December 2005
[49] Talwar, V., Nahrstedt, K., and S. Nath, "RSVP-SQoS: A Secure
RSVP Protocol", International Conf on Multimedia and
Exposition, Tokyo, Japan, August 2001.
[50] Jablon, D., "Strong Password-only Authenticated Key Exchange",
ACM Computer Communication Review, 26(5), pp. 5-26, October
1996.
Tschofenig & Graveman Informational [Page 44]
RFC 4230 RSVP Security Properties December 2005
Appendix A. Dictionary Attacks and Kerberos
Kerberos might be used with RSVP as described in this document.
Because dictionary attacks are often mentioned in relationship with
Kerberos, a few issues are addressed here.
The initial Kerberos AS_REQ request (without pre-authentication,
without various extensions, and without PKINIT) is unprotected. The
response message AS_REP is encrypted with the client's long-term key.
An adversary can take advantage of this fact by requesting AS_REP
messages to mount an off-line dictionary attack. Pre-authentication
([44]) can be used to reduce this problem. However, pre-
authentication does not entirely prevent dictionary attacks by an
adversary who can still eavesdrop on Kerberos messages along the path
between a mobile node and a KDC. With mandatory pre-authentication
for the initial request, an adversary cannot request a Ticket
Granting Ticket for an arbitrary user. On-line password guessing
attacks are still possible by choosing a password (e.g., from a
dictionary) and then transmitting an initial request that includes a
pre-authentication data field. An unsuccessful authentication by the
KDC results in an error message and thus gives the adversary a hint
to restart the protocol and try a new password.
There are, however, some proposals that prevent dictionary attacks.
The use of Public Key Cryptography for initial authentication [45]
(PKINIT) is one such solution. Other proposals use strong-password-
based authenticated key agreement protocols to protect the user's
password during the initial Kerberos exchange. [46] discusses the
security of Kerberos and also discusses mechanisms to prevent
dictionary attacks.
Appendix B. Example of User-to-PDP Authentication
The following Section describes an example of user-to-PDP
authentication. Note that the description below is not fully covered
by the RSVP specification and hence it should only be viewed as an
example.
Windows 2000, which integrates Kerberos into RSVP, uses a
configuration with the user authentication to the PDP as described in
[25]. The steps for authenticating the user to the PDP in an intra-
realm scenario are the following:
o Windows 2000 requires the user to contact the KDC and to request a
Kerberos service ticket for the PDP account AcsService in the
local realm.
Tschofenig & Graveman Informational [Page 45]
RFC 4230 RSVP Security Properties December 2005
o This ticket is then embedded into the AUTH_DATA element and
included in either the PATH or the RESV message. In the case of
Microsoft's implementation, the user identity encoded as a
distinguished name is encrypted with the session key provided with
the Kerberos ticket. The Kerberos ticket is sent without the
Kerberos authdata element that contains authorization information,
as explained in [25].
o The RSVP message is then intercepted by the PEP, which forwards it
to the PDP. [25] does not state which protocol is used to forward
the RSVP message to the PDP.
o The PDP that finally receives the message and decrypts the
received service ticket. The ticket contains the session key used
by the user's host to
* Encrypt the principal name inside the policy locator field of
the AUTH_DATA object and to
* Create the integrity-protected Keyed Message Digest field in
the INTEGRITY object of the POLICY_DATA element. The
protection described here is between the user's host and the
PDP. The RSVP INTEGRITY object on the other hand is used to
protect the path between the user's host and the first-hop
router, because the two message parts terminate at different
nodes, and different security associations must be used. The
interface between the message-intercepting, first-hop router
and the PDP must be protected as well.
* The PDP does not maintain a user database, and [25] describes
how the PDP may query the Active Directory (a LDAP based
directory service) for user policy information.
Appendix C. Literature on RSVP Security
Few documents address the security of RSVP signaling. This section
briefly describes some important documents.
Improvements to RSVP are proposed in [47] to deal with insider
attacks. Insider attacks are caused by malicious RSVP routers that
modify RSVP signaling messages in such a way that they cause harm to
the nodes participating in the signaling message exchange.
As a solution, non-mutable RSVP objects are digitally signed by the
sender. This digital signature is added to the RSVP PATH message.
Additionally, the receiver attaches an object to the RSVP RESV
message containing a "signed" history. This value allows
Tschofenig & Graveman Informational [Page 46]
RFC 4230 RSVP Security Properties December 2005
intermediate RSVP routers (by examining the previously signed value)
to detect a malicious RSVP node.
A few issues are, however, left open in this document. Replay
attacks are not covered, and it is therefore assumed that timestamp-
based replay protection is used. To identify a malicious node, it is
necessary that all routers along the path are able to verify the
digital signature. This may require a global public key
infrastructure and also client-side certificates. Furthermore, the
bandwidth and computational requirements to compute, transmit, and
verify digital signatures for each signaling message might place a
burden on a real-world deployment.
Authorization is not considered in the document, which might have an
influence on the implications of signaling message modification.
Hence, the chain-of-trust relationship (or this step in a different
direction) should be considered in relationship with authorization.
In [48], the above-described idea of detecting malicious RSVP nodes
is improved by addressing performance aspects. The proposed solution
is somewhere between hop-by-hop security and the approach in [47],
insofar as it separates the end-to-end path into individual networks.
Furthermore, some additional RSVP messages (e.g., feedback messages)
are introduced to implement a mechanism called "delayed integrity
checking." In [49], the approach presented in [48] is enhanced.
Authors' Addresses
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
EMail: Hannes.Tschofenig@siemens.com
Richard Graveman
RFG Security
15 Park Avenue
Morristown, NJ 07960
USA
EMail: rfg@acm.org
Tschofenig & Graveman Informational [Page 47]
RFC 4230 RSVP Security Properties December 2005
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Tschofenig & Graveman Informational [Page 48]
gemini://gemini.bortzmeyer.org/rfc-mirror/rfc4230.txt-- Leo's gemini proxy
-- Connecting to gemini.bortzmeyer.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/plain
-- Response ended
-- Page fetched on Mon May 6 11:24:53 2024