< draft-ietf-nsis-threats-05.txt   draft-ietf-nsis-threats-06.txt >
NSIS Working Group H. Tschofenig NSIS Working Group H. Tschofenig
Internet-Draft D. Kroeselberg Internet-Draft D. Kroeselberg
Expires: December 21, 2004 Siemens Expires: April 24, 2005 Siemens
June 22, 2004 October 24, 2004
Security Threats for NSIS Security Threats for NSIS
draft-ietf-nsis-threats-05.txt draft-ietf-nsis-threats-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of section 3 of RFC 3667. By submitting this Internet-Draft, each
and any of which I become aware will be disclosed, in accordance with 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. 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 other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
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."
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.
This Internet-Draft will expire on December 21, 2004. This Internet-Draft will expire on April 24, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
This threats document provides a detailed analysis of the security This threats document provides a detailed analysis of the security
threats relevant to the NSIS protocol suite. It calls attention to, threats relevant to the NSIS protocol suite. It calls attention to,
and helps with the understanding of, various security considerations and helps with the understanding of, various security considerations
in the NSIS Requirements, Framework, and Protocol proposals. This in the NSIS Requirements, Framework, and Protocol proposals. This
document does not describe vulnerabilities of specific parts of the document does not describe vulnerabilities of specific parts of the
NSIS protocol suite. NSIS protocol suite.
skipping to change at page 2, line 32 skipping to change at page 2, line 32
4.8 Denial of Service Attacks . . . . . . . . . . . . . . . . 22 4.8 Denial of Service Attacks . . . . . . . . . . . . . . . . 22
4.9 Disclosing the Network Topology . . . . . . . . . . . . . 23 4.9 Disclosing the Network Topology . . . . . . . . . . . . . 23
4.10 Unprotected Session or Reservation Ownership . . . . . . 23 4.10 Unprotected Session or Reservation Ownership . . . . . . 23
4.11 Attacks against the NTLP . . . . . . . . . . . . . . . . 25 4.11 Attacks against the NTLP . . . . . . . . . . . . . . . . 25
5. Security Considerations . . . . . . . . . . . . . . . . . . 26 5. Security Considerations . . . . . . . . . . . . . . . . . . 26
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 28 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 28
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 29 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 29
8.2 Informative References . . . . . . . . . . . . . . . . . . . 29 8.2 Informative References . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . 32 Intellectual Property and Copyright Statements . . . . . . . 32
1. Introduction 1. Introduction
Whenever a new protocol is developed or existing protocols are Whenever a new protocol is developed or existing protocols are
modified, threats to their security should be evaluated. To address modified, threats to their security should be evaluated. To address
security in the NSIS working group, a number of steps have been security in the NSIS working group, a number of steps have been
taken: taken:
NSIS Analysis Activities (see [I-D.ietf-nsis-rsvp-sec-properties] NSIS Analysis Activities (see [I-D.ietf-nsis-rsvp-sec-properties]
skipping to change at page 10, line 7 skipping to change at page 10, line 7
has to authenticate. The Initiator authenticates to the has to authenticate. The Initiator authenticates to the
man-in-the-middle adversary, who is then able to modify signaling man-in-the-middle adversary, who is then able to modify signaling
messages to mount DoS attacks or steal services that get billed to messages to mount DoS attacks or steal services that get billed to
the Initiator. In addition, it may be able to terminate the the Initiator. In addition, it may be able to terminate the
Initiator's NSIS messages and inject messages to a peer itself, Initiator's NSIS messages and inject messages to a peer itself,
therefore acting as the peer to the Initiator and as the Initiator therefore acting as the peer to the Initiator and as the Initiator
to the peer. This results in the Initiator wrongly believing that to the peer. This results in the Initiator wrongly believing that
it is talking to the "real" network, whereas it is actually it is talking to the "real" network, whereas it is actually
attached to an adversary. For this attack to be successful, attached to an adversary. For this attack to be successful,
pre-conditions have to hold which are described in the following pre-conditions have to hold which are described in the following
two cases: three cases:
Missing Authentication: Missing Authentication:
In the first case, this threat can be carried out because of In the first case, this threat can be carried out because of
missing authentication between neighboring peers: without missing authentication between neighboring peers: without
authentication a NI, NR, or NF is unable to detect an authentication a NI, NR, or NF is unable to detect an
adversary. However, in some practical cases authentication adversary. However, in some practical cases authentication
might be difficult to accomplish, either because the next peer might be difficult to accomplish, either because the next peer
is unknown, because of misbelieved trust relationships in parts is unknown, because of misbelieved trust relationships in parts
of the network, or because of the inability to establish proper of the network, or because of the inability to establish proper
skipping to change at page 11, line 43 skipping to change at page 11, line 43
An adversary might want to inject a bogus reply message forcing the An adversary might want to inject a bogus reply message forcing the
discovery message initiator to start a messaging association discovery message initiator to start a messaging association
establishment with either an adversary or with another NSIS node establishment with either an adversary or with another NSIS node
which is not along the path. Figure 3 describes the attack in more which is not along the path. Figure 3 describes the attack in more
detail for peer-to-peer addressed messages with a discovery detail for peer-to-peer addressed messages with a discovery
mechanism. For end-to-end addressed messages the attack is also mechanism. For end-to-end addressed messages the attack is also
applicable particularly if the adversary is located along the path applicable particularly if the adversary is located along the path
and able to intercept the discovery message which traverses the and able to intercept the discovery message which traverses the
adversary. The man-in-the-middle adversary might redirect to another adversary. The man-in-the-middle adversary might redirect to another
legimimate NSIS node. A malicious NSIS can be detected with the legimimate NSIS node. A malicious NSIS node can be detected with the
corresponding security mechanisms but a legitimate NSIS node which is corresponding security mechanisms but a legitimate NSIS node which is
not the next NSIS node along the path cannot be detected without not the next NSIS node along the path cannot be detected without
having topology knowledge. having topology knowledge.
+-----------+ Messaging Association +-----------+ Messaging Association
Message | Adversary | Establishment Message | Adversary | Establishment
Association +--->+ +<----------------+ Association +--->+ +<----------------+
Establish- | +----+------+ |(4) Establish- | +----+------+ |(4)
ment | IPx | | ment | IPx | |
(3)| |Discovery Reply v (3)| |Discovery Reply v
skipping to change at page 20, line 35 skipping to change at page 20, line 35
in a particular class of users or groups. This type of information in a particular class of users or groups. This type of information
either can be delivered as part of the authentication and key either can be delivered as part of the authentication and key
agreement procedure or has to be retrieved via separate protocols agreement procedure or has to be retrieved via separate protocols
from other entities. If an adversary manages to modify information from other entities. If an adversary manages to modify information
relevant for determining authorization or the outcome of the relevant for determining authorization or the outcome of the
authorization process itself, then theft of service might be authorization process itself, then theft of service might be
possible. possible.
4.6 Missing Non-Repudiation 4.6 Missing Non-Repudiation
Repudiation in this context refers to a problem where one party later Signaling for QoS often involves three parties: the user, a network
denies having taken a certain action (such as requesting a QoS that offer QoS reservations (referred as service provider) and a
reservation). Problems stemming from a lack of non-repudiation third party which guarantees that the party making the reservation
appear in two forms: actually receives a financial compensation (referred as trusted third
party).
On the one hand, from a service provider's point-of-view, the Repudiation in this context refers to a problem where either the user
following threat may be worth investigation. A user may deny having or the service provider later deny about the existence or some
issued a reservation request for which it was charged. The service parameters (e.g., volume or price) of a QoS reservation towards the
provider may then want to be able to prove that a particular user trusted third party. Problems stemming from a lack of
issued the reservation request in question. non-repudiation appear in two forms:
On the other hand, the same threat can be interpreted from a user's Service providers point-of-view:
point-of-view. A service provider may claim to have received a A user may deny having issued a reservation request for which it
number of reservation requests. The user in question thinks that it was charged. The service provider may then want to be able to
never issued those requests and wants to see a proof of correct prove that a particular user issued the reservation request in
service usage for a given set of QoS parameters. question.
In today's telecommunication networks, non-repudiation is not Users point-of-view:
provided. The user has to trust the network operator to meter the A service provider may claim to have received a number of
traffic correctly, collect and merge accounting data, and ensure that reservation requests from a particular user. The user in question
no unforeseen problems occur. If a signaling protocol with the may want to show that such a reservation requests have never been
non-repudiation property is desired for establishing QoS reservations issued and may want to see correct service usage records for a
for authorized resources, this impacts the protocol design. given set of QoS parameters.
Non-repudiation poses additional requirements on the security In today's networks, non-repudiation is not provided. As such, it
mechanisms, because public-key cryptography is needed to provide it. might be difficult to introduce with NSIS signaling. The user has to
Because this would normally increase the overall cost for security, trust the network operator to meter the traffic correctly, collect
threats related to missing non-repudiation are only considered and merge accounting data, and ensure that no unforeseen problems
relevant in certain specific cases (e.g., specific authorization occur. If a signaling protocol with the non-repudiation property is
mechanisms) and not for general NSIS signaling. desired for establishing QoS reservations then it certainly impacts
the protocol design.
Non-repudiation functionality additional places requirements on the
security mechanisms. Hence, a solution would normally increase the
overhead of a security solution. Threats related to missing
non-repudiation are only considered relevant in certain specific
scenarios and for specific NSLPs.
4.7 Malicious NSIS Entity 4.7 Malicious NSIS Entity
Network elements within a domain (intra-domain) experience a Network elements within a domain (intra-domain) experience a
different trust relationship with regard to the security protection different trust relationship with regard to the security protection
of signaling messages compared with edge NSIS entities. It is of signaling messages compared with edge NSIS entities. It is
assumed that edge NSIS entities are responsible for performing assumed that edge NSIS entities are responsible for performing
cryptographic processing (authentication, integrity and replay cryptographic processing (authentication, integrity and replay
protection, authorization, and accounting) for signaling messages protection, authorization, and accounting) for signaling messages
arriving from the outside. This prevents unprotected signaling arriving from the outside. This prevents unprotected signaling
skipping to change at page 29, line 9 skipping to change at page 29, line 9
particular, provided good proposals for regrouping and restructuring particular, provided good proposals for regrouping and restructuring
the material. the material.
A final review was given by Michael Richardson. We thank him for his A final review was given by Michael Richardson. We thank him for his
detailed comments. detailed comments.
8. References 8. References
8.1 Normative References 8.1 Normative References
[I-D.ietf-nsis-fw]
Hancock, R., "Next Steps in Signaling: Framework",
draft-ietf-nsis-fw-06 (work in progress), July 2004.
[RFC3726] Brunner, M., "Requirements for Signaling Protocols", RFC [RFC3726] Brunner, M., "Requirements for Signaling Protocols", RFC
3726, April 2004. 3726, April 2004.
8.2 Informative References 8.2 Informative References
[ALN00] Aura, T., Leiwo, J. and P. Nikander, "Towards Network [ALN00] Aura, T., Leiwo, J. and P. Nikander, "Towards Network
Denial of Service Resistant Protocols, In Proceedings of Denial of Service Resistant Protocols, In Proceedings of
the 15th International Information Security Conference the 15th International Information Security Conference
(IFIP/SEC 2000), Beijing, China", August 2000, <ALN00>. (IFIP/SEC 2000), Beijing, China", August 2000, <ALN00>.
[AN97] Aura, T. and P. Nikander, "Stateless Connections", In [AN97] Aura, T. and P. Nikander, "Stateless Connections", In
Proceedings of the International Conference on Information Proceedings of the International Conference on Information
and Communications Security (ICICS'97), Lecture Notes in and Communications Security (ICICS'97), Lecture Notes in
Computer Science 1334, Springer", 1997, <AN97>. Computer Science 1334, Springer", 1997, <AN97>.
[I-D.braden-2level-signal-arch] [I-D.braden-2level-signal-arch]
Braden, R. and B. Lindell, "A Two-Level Architecture for Braden, R. and B. Lindell, "A Two-Level Architecture for
Internet Signaling", draft-braden-2level-signal-arch-01 Internet Signaling", draft-braden-2level-signal-arch-01
(work in progress), November 2002, (work in progress), November 2002.
<reference.I-D.braden-2level-signal-arch.xml>.
[I-D.ietf-ipv6-flow-label] [I-D.ietf-ipv6-flow-label]
Rajahalme, J., Conta, A., Carpenter, B. and S. Deering, Rajahalme, J., Conta, A., Carpenter, B. and S. Deering,
"IPv6 Flow Label Specification", "IPv6 Flow Label Specification",
draft-ietf-ipv6-flow-label-09 (work in progress), December draft-ietf-ipv6-flow-label-09 (work in progress), December
2003, <reference.I-D.ietf-ipv6-flow-label.xml>. 2003.
[I-D.ietf-nsis-fw]
Hancock, R., Freytsis, I., Karagiannis, G., Loughney, J.
and S. Van den Bosch, "Next Steps in Signaling:
Framework", draft-ietf-nsis-fw-05 (work in progress),
October 2003.
[I-D.ietf-nsis-nslp-natfw] [I-D.ietf-nsis-nslp-natfw]
Stiemerling, M., Tschofenig, H., Martin, M. and C. Aoun, Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer
"A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-03 (work in
draft-ietf-nsis-nslp-natfw-02 (work in progress), May progress), July 2004.
2004.
[I-D.ietf-nsis-ntlp] [I-D.ietf-nsis-ntlp]
Schulzrinne, H. and R. Hancock, "GIMPS: General Internet Schulzrinne, H., "GIMPS: General Internet Messaging
Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-02 Protocol for Signaling", draft-ietf-nsis-ntlp-03 (work in
(work in progress), May 2004. progress), July 2004.
[I-D.ietf-nsis-qos-nslp] [I-D.ietf-nsis-qos-nslp]
Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for
Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-03 Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-04
(work in progress), May 2004. (work in progress), July 2004.
[I-D.ietf-nsis-rsvp-sec-properties] [I-D.ietf-nsis-rsvp-sec-properties]
Tschofenig, H. and R. Graveman, "RSVP Security Tschofenig, H., "RSVP Security Properties",
Properties", draft-ietf-nsis-rsvp-sec-properties-04 (work draft-ietf-nsis-rsvp-sec-properties-05 (work in progress),
in progress), February 2004. September 2004.
[I-D.ietf-nsis-signalling-analysis] [I-D.ietf-nsis-signalling-analysis]
Manner, J., Fu, X. and P. Pan, "Analysis of Existing Manner, J., "Analysis of Existing Quality of Service
Quality of Service Signaling Protocols", Signaling Protocols",
draft-ietf-nsis-signalling-analysis-04 (work in progress), draft-ietf-nsis-signalling-analysis-04 (work in progress),
May 2004. May 2004.
[RFC1809] Partridge, C., "Using the Flow Label Field in IPv6", RFC [RFC1809] Partridge, C., "Using the Flow Label Field in IPv6", RFC
1809, June 1995. 1809, June 1995.
[RFC2745] Terzis, A., Braden, B., Vincent, S. and L. Zhang, "RSVP [RFC2745] Terzis, A., Braden, B., Vincent, S. and L. Zhang, "RSVP
Diagnostic Messages", RFC 2745, January 2000. Diagnostic Messages", RFC 2745, January 2000.
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
 End of changes. 21 change blocks. 
60 lines changed or deleted 66 lines changed or added

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