draft-ietf-nsis-rsvp-sec-properties-04.txt   draft-ietf-nsis-rsvp-sec-properties-05.txt 
NSIS NSIS
Internet Draft Hannes Tschofenig Internet Draft Hannes Tschofenig
Siemens Siemens
Richard Graveman Richard Graveman
RFG Security RFG Security
Document: Document:
draft-ietf-nsis-rsvp-sec-properties-04.txt draft-ietf-nsis-rsvp-sec-properties-05.txt
Expires: August 2004 February 2004 Expires: March 2005 September 2004
RSVP Security Properties RSVP Security Properties
<draft-ietf-nsis-rsvp-sec-properties-04.txt> <draft-ietf-nsis-rsvp-sec-properties-05.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is subject to all provisions
with all provisions of Section 10 of RFC2026. of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress". reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document summarizes the security properties of RSVP. The goal This document summarizes the security properties of RSVP. The goal
of this analysis is to benefit from previous work done on RSVP and of this analysis is to benefit from previous work done on RSVP and
to capture knowledge about past activities. to capture knowledge about past activities.
Table of Contents Table of Contents
1. Introduction..................................................2 1. Introduction..................................................2
2. Terminology and Architectural Assumptions.....................3 2. Terminology and Architectural Assumptions.....................3
3. Overview......................................................5 3. Overview......................................................5
3.1 The RSVP INTEGRITY Object.................................5 3.1 The RSVP INTEGRITY Object.................................5
3.2 Security Associations.....................................7 3.2 Security Associations.....................................7
3.3 RSVP Key Management Assumptions...........................8 3.3 RSVP Key Management Assumptions...........................8
3.4 Identity Representation...................................8 3.4 Identity Representation...................................8
3.5 RSVP Integrity Handshake.................................12 3.5 RSVP Integrity Handshake.................................12
4. Detailed Security Property Discussion........................14 4. Detailed Security Property Discussion........................13
4.1 Network Topology.........................................14 4.1 Network Topology.........................................13
4.2 Host/Router..............................................15 4.2 Host/Router..............................................14
4.3 User to PEP/PDP..........................................19 4.3 User to PEP/PDP..........................................18
4.4 Communication between RSVP-Aware Routers.................27 4.4 Communication between RSVP-Aware Routers.................27
5. Miscellaneous Issues.........................................29 5. Miscellaneous Issues.........................................29
5.1 First Hop Issue..........................................29 5.1 First Hop Issue..........................................29
5.2 Next-Hop Problem.........................................29 5.2 Next-Hop Problem.........................................29
5.3 Last-Hop Issue...........................................32 5.3 Last-Hop Issue...........................................32
5.4 RSVP and IPsec protected data traffic....................33 5.4 RSVP and IPsec protected data traffic....................33
5.5 End-to-End Security Issues and RSVP......................35 5.5 End-to-End Security Issues and RSVP......................35
5.6 IPsec protection of RSVP signaling messages..............35 5.6 IPsec protection of RSVP signaling messages..............35
5.7 Authorization............................................36 5.7 Authorization............................................36
6. Conclusions..................................................37 6. Conclusions..................................................37
7. Security Considerations......................................39 7. Security Considerations......................................39
8. IANA considerations..........................................39 8. IANA considerations..........................................39
9. Acknowledgments..............................................39 9. Acknowledgments..............................................39
10. Normative References........................................42 10. Normative References........................................41
11. Informative References......................................42 11. Informative References......................................42
Author's Contact Information....................................45 Author's Contact Information....................................45
Full Copyright Statement........................................46
Acknowledgement.................................................46
1. Introduction 1. Introduction
As the work of the NSIS working group has begun, there are also As the work of the NSIS working group has begun, there are also
concerns about security and its implications for the design of a concerns about security and its implications for the design of a
signaling protocol. In order to understand the security properties signaling protocol. In order to understand the security properties
and available options of RSVP a number of documents have to be read. and available options of RSVP a number of documents have to be read.
This document summarizes the security properties of RSVP and is part This document summarizes the security properties of RSVP and is part
of the overall process of analyzing other signaling protocols and of the overall process of analyzing other signaling protocols and
learning from their design considerations. This document should also learning from their design considerations. This document should also
skipping to change at page 22, line 25 skipping to change at page 21, line 31
risks of denial of service attacks. Additionally, the large risks of denial of service attacks. Additionally, the large
processing, memory, and bandwidth utilization should be considered. processing, memory, and bandwidth utilization should be considered.
Fragmentation might also be an issue here. Fragmentation might also be an issue here.
If the INTEGRITY object is not included in the POLICY_DATA element If the INTEGRITY object is not included in the POLICY_DATA element
or not sent to the PDP, then we have to make the following or not sent to the PDP, then we have to make the following
observations: observations:
a) For the digital signature case, only the replay protection a) For the digital signature case, only the replay protection
provided by the digital signature algorithm can be used. It is provided by the digital signature algorithm can be used. It is
not not clear, however, whether this usage was anticipated or not.
clear, however, whether this usage was anticipated or not. Hence, Hence, we might assume that replay protection is based on the
we might assume that replay protection is based on the
availability of the RSVP INTEGRITY object used with a security availability of the RSVP INTEGRITY object used with a security
association that is established by other means. association that is established by other means.
b) Including only the Kerberos session ticket is insufficient, b) Including only the Kerberos session ticket is insufficient,
because freshness is not provided (since the Kerberos because freshness is not provided (since the Kerberos
Authenticator is missing). Obviously there is no guarantee that Authenticator is missing). Obviously there is no guarantee that
the user actually followed the Kerberos protocol and was able to the user actually followed the Kerberos protocol and was able to
decrypt the received TGS_REP (or in rare cases the AS_REP if a decrypt the received TGS_REP (or in rare cases the AS_REP if a
session ticket is requested with the initial AS_REQ). session ticket is requested with the initial AS_REQ).
skipping to change at page 34, line 5 skipping to change at page 34, line 5
SAD by providing the flow identifiers as input parameters and the SAD by providing the flow identifiers as input parameters and the
SPI as an output parameter. SPI as an output parameter.
b) RFC 2207 assumes end-to-end IPsec protection of the data traffic. b) RFC 2207 assumes end-to-end IPsec protection of the data traffic.
If IPsec is applied in a nested fashion, then parts of the path do If IPsec is applied in a nested fashion, then parts of the path do
not experience QoS treatment. This can be treated as a tunneling not experience QoS treatment. This can be treated as a tunneling
problem, but it is initiated by the end host. A figure better problem, but it is initiated by the end host. A figure better
illustrates the problem in the case of enforcing secure network illustrates the problem in the case of enforcing secure network
access: access:
+------+ +---------------+ +--------+ +------ +------+ +---------------+ +--------+ +-----+
+ | Host | | Security | | Router | | Host|
| Host | | Security | | Router | | Host | A | | Gateway (SGW) | | Rx | | B |
| +--+---+ +-------+-------+ +----+---+ +--+--+
| A | | Gateway (SGW) | | Rx | | B
|
+--+---+ +-------+-------+ +----+---+ +--+---
+
| | | | | | | |
|IPsec-Data( | | | |IPsec-Data( | | |
| OuterSrc=A, | | | | OuterSrc=A, | | |
| OuterDst=SGW, | | | | OuterDst=SGW, | | |
| SPI=SPI1, | | | | SPI=SPI1, | | |
| InnerSrc=A, | | | | InnerSrc=A, | | |
| OuterDst=B, | | | | OuterDst=B, | | |
| Protocol=X, |IPsec-Data( | | | Protocol=X, |IPsec-Data( | |
| SrcPort=Y, | SrcIP=A, | | | SrcPort=Y, | SrcIP=A, | |
| DstPort=Z) | DstIP=B, | | | DstPort=Z) | DstIP=B, | |
skipping to change at page 38, line 38 skipping to change at page 38, line 36
of service attacks, and other problems. of service attacks, and other problems.
* Public key authentication and user identity confidentiality * Public key authentication and user identity confidentiality
provided with RSVP require some improvement. provided with RSVP require some improvement.
* Public key based user authentication only provides entity * Public key based user authentication only provides entity
authentication. An additional security association is required to authentication. An additional security association is required to
protect signaling messages. protect signaling messages.
* Data origin authentication should not be provided by non-RSVP * Data origin authentication should not be provided by non-RSVP
nodes nodes (such as the PDP). Such a procedure could be accomplished by
(such as the PDP). Such a procedure could be accomplished by entity authentication during the authentication and key exchange
entity phase.
authentication during the authentication and key exchange phase.
* Authorization and charging should be better integrated into the * Authorization and charging should be better integrated into the
base protocol. base protocol.
* Selective message protection should be provided. A protected * Selective message protection should be provided. A protected
message should be recognizable from a flag in the header. message should be recognizable from a flag in the header.
* Confidentiality protection is missing and should therefore be * Confidentiality protection is missing and should therefore be
added added
to the protocol. The general principle is that protocol designers to the protocol. The general principle is that protocol designers
skipping to change at page 40, line 27 skipping to change at page 40, line 21
by the RSVP specification and hence it should only be seen as an by the RSVP specification and hence it should only be seen as an
example. example.
Windows 2000, which integrates Kerberos into RSVP, uses a Windows 2000, which integrates Kerberos into RSVP, uses a
configuration with the user authentication to the PDP as described configuration with the user authentication to the PDP as described
in [MADS01]. The steps for authenticating the user to the PDP in an in [MADS01]. The steps for authenticating the user to the PDP in an
intra-realm scenario are the following: intra-realm scenario are the following:
- Windows 2000 requires the user to contact the KDC and to request a - Windows 2000 requires the user to contact the KDC and to request a
Kerberos service ticket for the PDP account AcsService in the Kerberos service ticket for the PDP account AcsService in the
local local realm.
realm.
- This ticket is then embedded into the AUTH_DATA element and - This ticket is then embedded into the AUTH_DATA element and
included in either the PATH or the RESV message. In case of included in either the PATH or the RESV message. In case of
Microsoft's implementation, the user identity encoded as a Microsoft's implementation, the user identity encoded as a
distinguished name is encrypted with the session key provided with distinguished name is encrypted with the session key provided with
the Kerberos ticket. The Kerberos ticket is sent without the the Kerberos ticket. The Kerberos ticket is sent without the
Kerberos authdata element that contains authorization information, Kerberos authdata element that contains authorization information,
as explained in [MADS01]. as explained in [MADS01].
- The RSVP message is then intercepted by the PEP, which forwards it - The RSVP message is then intercepted by the PEP, which forwards it
skipping to change at page 40, line 45 skipping to change at page 40, line 38
Kerberos authdata element that contains authorization information, Kerberos authdata element that contains authorization information,
as explained in [MADS01]. as explained in [MADS01].
- The RSVP message is then intercepted by the PEP, which forwards it - The RSVP message is then intercepted by the PEP, which forwards it
to the PDP. [MADS01] does not state which protocol is used to to the PDP. [MADS01] does not state which protocol is used to
forward the RSVP message to the PDP. forward the RSVP message to the PDP.
- The PDP that finally receives the message decrypts the received - The PDP that finally receives the message decrypts the received
service ticket. The ticket contains the session key used by the service ticket. The ticket contains the session key used by the
user's host to user's host to
a) Encrypt the principal name inside the policy locator field of a) Encrypt the principal name inside the policy locator field of
the AUTH_DATA object and to the AUTH_DATA object and to
b) Create the integrity-protected Keyed Message Digest field in b) Create the integrity-protected Keyed Message Digest field in
the the INTEGRITY object of the POLICY_DATA element. The protection
INTEGRITY object of the POLICY_DATA element. The protection
described here is between the user's host and the PDP. The RSVP 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 INTEGRITY object on the other hand is used to protect the path
between the user's host and the first-hop router, because the between the user's host and the first-hop router, because the
two message parts terminate at different nodes and different two message parts terminate at different nodes and different
security associations must be used. The interface between the security associations must be used. The interface between the
message-intercepting, first-hop router and the PDP must be message-intercepting, first-hop router and the PDP must be
protected as well. protected as well.
c) The PDP does not maintain a user database, and [MADS01] c) The PDP does not maintain a user database, and [MADS01]
describes how the PDP may query the Active Directory (a LDAP describes how the PDP may query the Active Directory (a LDAP
based directory service) for user policy information. based directory service) for user policy information.
skipping to change at page 46, line 4 skipping to change at page 45, line 44
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
81739 Munich 81739 Munich
Germany Germany
Email: Hannes.Tschofenig@siemens.com Email: Hannes.Tschofenig@siemens.com
Richard Graveman Richard Graveman
RFG Security, LLC RFG Security, LLC
15 Park Avenue 15 Park Avenue
Morristown, NJ 07960 USA Morristown, NJ 07960 USA
email: rfg@acm.org email: rfg@acm.org
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Intellectual Property Statement
This document and translations of it may be copied and furnished to The IETF takes no position regarding the validity or scope of any
others, and derivative works that comment on or otherwise explain it Intellectual Property Rights or other rights that might be claimed
or assist in its implementation may be prepared, copied, published to pertain to the implementation or use of the technology described
and distributed, in whole or in part, without restriction of any in this document or the extent to which any license under such
kind, provided that the above copyright notice and this paragraph rights might or might not be available; nor does it represent that
are it has made any independent effort to identify any such rights.
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Information on the procedures with respect to rights in RFC
revoked by the Internet Society or its successors or assigns. documents can be found in BCP 78 and BCP 79.
This document and the information contained herein is provided on an Copies of IPR disclosures made to the IETF Secretariat and any
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING assurances of licenses to be made available, or the result of an
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING attempt made to obtain a general license or permission for the use
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION of such proprietary rights by implementers or users of this
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF specification can be obtained from the IETF on-line IPR repository
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. at http://www.ietf.org/ipr.
Acknowledgement 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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/