Internet DRAFT - draft-kaeo-distsec-framework
draft-kaeo-distsec-framework
Internet Engineering Task Force M. Kaeo
Internet-Draft Double Shot Security
Expires: August 6, 2006 P. Savola
CSC/FUNET
February 2, 2006
Distributed Security Framework
draft-kaeo-distsec-framework-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 6, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Security policy enforcement is becoming increasingly challenging as
the trend to utilize mobile and nomadic nodes in networked
communications continues to grow. This document will enumerate the
problem statement and threat model and will describe how a
distributed security framework can address the threats related to
these problems.
Kaeo & Savola Expires August 6, 2006 [Page 1]
Internet-Draft Distributed Security Framework February 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Network versus Host-Based Security Models . . . . . . . . . . 4
4.1. Topology Constraints . . . . . . . . . . . . . . . . . . . 4
4.2. Flexibility . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Operational Deployment . . . . . . . . . . . . . . . . . . 5
4.4. Verifiability . . . . . . . . . . . . . . . . . . . . . . 5
5. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Unauthorized Control or Unacceptable Use . . . . . . . . . 5
5.2. Host Vulnerability Detection . . . . . . . . . . . . . . . 6
6. Threat Model Considerations . . . . . . . . . . . . . . . . . 6
6.1. Users Bypassing Corporate Security Policies . . . . . . . 6
6.2. Physical Access to Hosts . . . . . . . . . . . . . . . . . 7
6.3. L2/L3 Network Authorization . . . . . . . . . . . . . . . 7
6.4. Host Identification and Blocking . . . . . . . . . . . . . 8
6.5. Correct Policy Implementation . . . . . . . . . . . . . . 8
6.6. Distributed Information Security . . . . . . . . . . . . . 9
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11. Informative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Kaeo & Savola Expires August 6, 2006 [Page 2]
Internet-Draft Distributed Security Framework February 2006
1. Introduction
Security policy enforcement is becoming increasingly challenging as
the trend to utilize mobile and nomadic nodes in networked
communication continues to grow. Whereas initially many network
architectures revolved around network-based security solutions, end-
nodes are now becoming as important in enforcing security policies as
the network devices. Home automation devices, PDA's, laptops, and
mobile phones are all IP-enabled and capable of connecting
dynamically between different networks. Additionally, more peer-to-
peer and GRID applications are becoming available that rely on an
end-to-end paradigm that is made possible by IPv6.
The nomadic capabilities for end-nodes make it difficult to
effectively upgrade filtering and monitoring rules on devices that
have no standards- based mechanisms to dynamically exchange,
distribute and/or enforce their policies. This document will
enumerate the problem statement and threat model and will describe
how a distributed security framework can address the threats related
to these problems.
2. Scope
The main focus of a distributed security solution is on reducing the
risk of a security breach, minimizing any damage in the local network
environment should a security breach occur, and to isolate the
misbehaving or vulnerable nodes from the network.
Additionally, the scope of this work will include bi-directional,
auditable policy enforcement. Take for example a user who installs a
web server package yet port 80 is not open on the host. It should be
possible to query the user as to which policy he/she would want to
apply. Additionally, appropriate authentication may be required to
apply the policy - i.e. appropriate credentials need to be supplied
to authorize applying the policy. As mobile nodes move to different
networks, this could effectively help in creating an auditable self-
enforcement policy.
Rather than dividing this work into separate problem sets (i.e.
distributed firewall, distributed IDS, etc), the problem solution
needs to encompass all aspects of distributed security to provide a
comprehensive interoperable solution that relates to the overall goal
of communicating and possibly modifying security rules between
varying host-based and network-based security components.
What is specifically out of scope is how to "merge" policy when a
visiting host and the local network have individual and conflicting
Kaeo & Savola Expires August 6, 2006 [Page 3]
Internet-Draft Distributed Security Framework February 2006
policy views. Also out of scope is protecting devices such as
routers and switches which, although they may need to participate in
the enforcement of the distributive security framework, have existing
tools that already provide appropriate security measures.
3. Problem Statement
There are four distinct problems that a distributive security
solution will address:
1. As mobile nodes move on and off varying networks, there is no
consistent policy enforcement, i.e. having a capability to push a
specific policy down to a node and having the node be responsible
for enforcing it, both on local and remote networks.
2. There is no standardized mechanism for distributed feedback from
IDSs [1] as input to centralized policy / decision making policy.
3. There is no standardized mechanism to isolate misbehaving nodes
from the network once the node has already been connected.
4. There is no standardized mechanism for using policies which can't
be enforced by network elements, for example which application
versions are used by a specific host.
4. Network versus Host-Based Security Models
Security models used to be based more on network-centric solutions
where firewalls and intrusion detection systems were placed in
varying places in the network separating the trusted from the un-
trusted segments. However, as the distinction between trusted and
un-trusted networks became more blurred, host-based firewalls and
intrusion detection systems started becoming more prevalent. The
tradeoffs between the two models are largely based on granularity of
control versus simplicity in management, and a distributed security
solution will try to find a balance between the models. We summarize
some of the most important differences below.
4.1. Topology Constraints
In network-centric solutions, the host is constrained to the security
policy that is enforced for the network segment that it is connected
on and there is no protection between hosts that are on the same LAN
segment. A host-based security solution does not have any topology
constraints.
Kaeo & Savola Expires August 6, 2006 [Page 4]
Internet-Draft Distributed Security Framework February 2006
4.2. Flexibility
Because of the topology constraints, a network based security
enforcement has limited flexibility. Host-based security solutions
can more effectively enforce end-to-end security policies based on a
combination of user identity, network location and specific
application. In some instance where nodes are more trusted (perhaps
because they are static), they may have a less restrictions than a
general policy applied to nomadic nodes attached to the same network
segment.
4.3. Operational Deployment
A 'per-network' security policy is often easier to administrate than
a 'per- host' security policy because there are fewer elements
involved. While the same security policy may be enforced on all
nodes of each network connected to a firewall, it may also be
possible to have separate policies for all hosts. If the latter is
warranted, then the operational considerations are similar for a
network versus host based enforcement system.
4.4. Verifiability
The network administration must know the policy that should be used
in the network, and must also be able to verify whether the policy is
being correctly enforced. This is relatively straightforward with
network-only security mechanisms, while this is challenging with a
host-based mechanism.
5. Threat Model
At a generic level, most threat models pertain to how data systems
can be maliciously compromised such that they become under
unauthorized control, how information is susceptible to modification,
re-direction, corruption, spoofing or how critical networked services
are rendered unavailable. This section describes the threats that
are relevant to a distributed security environment.
5.1. Unauthorized Control or Unacceptable Use
There are many cases where unbeknownst to the user, their host has
been compromised, and the host is at least partially out of control.
For example, a host could be:
o participating in a remotely-controlled malicious activity (e.g.,
as part of a 'botnet'), such as DDoS attacks, sending unsolicited
email messages, performing port scanning, etc.
Kaeo & Savola Expires August 6, 2006 [Page 5]
Internet-Draft Distributed Security Framework February 2006
o participating in an uncontrolled improper activity (e.g.,
spreading a worm or a virus).
There is a need to be able to better detect when a host has been
compromised and to ensure that the compromised host can be taken off
the network to avoid further malicious behavior. Today this is
typically done in a manual fashion where, if a network administrator
learns of a botnet participant, the relevant people are notified to
fix the problem. This can sometimes take days and/or weeks since the
administrators who may detect the problem could belong to different
organizations.
5.2. Host Vulnerability Detection
Many host operating systems are susceptible to attacks which take
advantage of known implementation bugs or protocol deficiencies to
cause inappropriate behavior.
It is necessary to be able to detect whether a particular operating
system is susceptible to known vulnerabilities and whether hosts
require upgrades or downgrades of their operating system to mitigate
the risk of being susceptible to the attacks. While network-based
security scanners can detect some amount of these vulnerabilities, a
more accurate and complete set of information could be obtained from
the host itself.
6. Threat Model Considerations
While network perimeter protection via firewalls has evolved to
include host-based protection (anti-spam, anti-virus, and anti-
spyware software, software version control, personal firewalls, host-
based intrusion detection systems, etc.), there is limited
interoperable coordination between the varying systems. Some
proprietary implementations exist which attempt to coordinate the
policy distribution and communication between varying security
components in a network. The issues related to the threat model are
addressed and NOT addressed by this coordinated effort as shown
below.
6.1. Users Bypassing Corporate Security Policies
Users are often keen (and even instructed by helpdesks) to turn off
firewalls, virus scanners, etc. when debugging a problem or when such
behavior is deemed undesirable (e.g., hampering playing a network-
based game or running a peer-to-peer software).
In enterprise scenarios, or where this is recognized as a problem, a
Kaeo & Savola Expires August 6, 2006 [Page 6]
Internet-Draft Distributed Security Framework February 2006
solution typically is to withhold administrator privileges from
ordinary users preventing them from performing these actions.
If the user has administrator access to the system, it is not
possible to prevent these actions, short of more extensive security
framework (e.g., "trusted computing").
Therefore we assume that the users are either knowledgeable enough or
must not have the privileges to turn off the required security
services.
XXX: "How well do these policies get enforced now with stuff like
HIDS or AV?"
6.2. Physical Access to Hosts
In case of laptops and workstations, the users are expected to have
physical access to the systems. In some environments, the IT support
will have password-protected BIOS setups or other countermeasures to
prevent users from, e.g., rebooting a system and performining
administrative password recovery. While these countermeasures and
policies might mitigate the threat of misbehaving users, we cannot
assume the hosts would be physically safe from user's actions.
If a host falls into the wrong hands (e.g., a stolen laptop), we
assume that the system would be sufficiently encrypted.
Alternatively, configurations must not include secrets which would be
of significant information value in assisting a security breach.
6.3. L2/L3 Network Authorization
It is assumed that the security of network access has been chosen
according to the requirements of a site.
For example, one could use 802.1x and EAP to control network access,
using certificates and/or usernames and passwords. Some sites might
view this as an overkill in their environment (e.g., where there is
deemed to be sufficient physical security) and have no protections,
or just perform MAC-address locking in the switch equipment. Other
sites might require no or only minimal L2 authorizationm but require
encrypted VPNs from all the hosts to VPN gateways to eliminate
eavesdropping and hijacking.
Sites may also have different requirements for layer 3 network access
control, i.e., which IP address the user gets and whether the address
can be changed/spoofed by the user if need be. In some rare cases,
DHCP authentication may be in use, though it does not prevent manual
configuration of another address. In IPv6, SEND [2] may be
Kaeo & Savola Expires August 6, 2006 [Page 7]
Internet-Draft Distributed Security Framework February 2006
applicable. Other solutions may exist.
Distributed security should be able to work within any of these
scenarios according to the site's security requirements.
6.4. Host Identification and Blocking
XXX: "This is, of course, a standard technique in modern 802
networks."
When security policy is communicated and applied, the hosts need to
be reliably identified.
The mechanisms by which this is done depend on the security
requirements of the site. IP address, hostname, MAC-address, etc. or
some combination thereof may or may not be sufficient; sometimes
certificates may need to be used; if 802.1x and EAP were used for L2
network access or VPNs for L3 access, the user identification
credentials used there could be used here as well.
We also need to consider how access to the host can be blocked
reliably (e.g., because its security is not at a sufficiently high
level, because it has been compromised or because it hasn't been
checked yet).
o The most reliable way would be using strong identification (XXX:
need spelling out?), but that cannot be expected to be readily
available (and inspecting it on the wire would probably require
that each host would use VPNs).
o The easiest way is to use IP addresses. However, the user could
just change an IP address and try again; presumably, all IP
addresses (until verified) would need to be blocked by default.
Then the user could try to hijack another, already-authorized
user's IP address. However, this can often be noticed and even
prevented, depending on the security requirements of the site.
6.5. Correct Policy Implementation
Distributed security uses policies and checks to verify that the host
should be secure enough. There are a couple of assumptions
associated with this requirement:
o The host (even if infected) will not lie about the checks, or
there are other (e.g., network-based) mechanisms to detect the
most blatant lies or other anomalous behaviour. In the absence of
"trusted computing", for example kernel vulnerabilities could
allow an attacker to hide their presence or activities.
Kaeo & Savola Expires August 6, 2006 [Page 8]
Internet-Draft Distributed Security Framework February 2006
o The policy language and mechanisms are expressive enough. For
example, it may not always be possible to identify "good" and
"bad" versions just by looking at a version string (especially as
may be the case for "backported" updates). The implementations
would need to include more extensive mechanisms for noticing and
reporting problems. There are potential managerial problems in
ensuring that, for example, the correct checksums of software are
known. There are also potential combinatorial problems: it may
not just be a matter of having specific versions of software but
ensuring that the correct combination of versions are present.
6.6. Distributed Information Security
Distributed security mechanisms need to be able to block the hosts at
policy enforcement points. If there is communication between the
IDSs or other mechanisms detecting anomalous behaviour, the
communication should be at least authenticated and integrity-
protected.
The communication of a host and policy controllers should be
sufficiently secure that the information cannot be altered by man-in-
the-middle or other attackers. Typically this calls for encryption,
integrity protection and sufficient authentication.
7. Conclusion
A more coordinated effort between the network-based and host-based
security components would provide a more effective and auditable
security policy enforcement.
8. Acknowledgements
This document combines and obsoletes an earlier, more detailed
framework document [3] and a separate threat model document [4]. The
most notable contributions to the earlier documents were made by Jari
Arkko, Elwyn Davies, Sam Hartman, Eric Rescorla, and Hannes
Tschofenig.
9. Security Considerations
This memo is all about the distributed security and its threat
models.
The most important thing to note is that distributed security is not
a perfect solution; as it needs to rely on (to some degree) the
Kaeo & Savola Expires August 6, 2006 [Page 9]
Internet-Draft Distributed Security Framework February 2006
users' and the host OS's correct behavior. In cases where this
assumption does not hold stricter measures will be necessary.
10. IANA Considerations
This memo does not require any IANA action.
11. Informative References
[1] Wood, M. and M. Erlinger, "Intrusion Detection Mesage Exchange
Requirements", draft-ietf-idwg-requirements-10 (work in
progress), October 2002.
[2] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[3] Vives, A., "Distributed Security Framework",
draft-vives-distsec-framework-00 (work in progress),
August 2005.
[4] Savola, P., "Distributed Security Threat Model",
draft-savola-distsec-threat-model-01 (work in progress),
October 2005.
Authors' Addresses
Merike Kaeo
Double Shot Security
520 Washington Blvd. #363
Marina Del Rey, CA 90292
USA
Email: kaeo@merike.com
Pekka Savola
CSC/FUNET
Espoo
Finland
Email: psavola@funet.fi
Full Copyright Statement
Kaeo & Savola Expires August 6, 2006 [Page 10]
Internet-Draft Distributed Security Framework February 2006
Copyright (C) The Internet Society (2006).
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kaeo & Savola Expires August 6, 2006 [Page 11]
