OPSEC Working Group (proposed) G. Jones
Internet-Draft The MITRE Corporation
Expires: October 20, 2004 R. Callon
Juniper Networks
M. Kaeo
Double Shot Security
April 21, 2004
Framework for Operational Security Requirements for IP Network
Infrastructure
draft-jones-opsec-framework-00
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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 October 20, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document outlines work to be done and documents to be produced
by the proposed Operational Security Requirements (OPSEC) Working
Group. The goal of the working group is to codify knowledge about
feature sets that are required to securely deploy and operate managed
network elements providing transit services at OSI layers 2 and 3,
Jones, et al. Expires October 20, 2004 [Page 1]
Internet-Draft OpSec Framework April 2004
i.e. switches and routers. The intent is to provide clear, concise
documentation of requirements necessary for operating networks
securely, to assist network operators in communicating their
requirements to vendors, and to provide vendors with input that is
useful for building more secure devices. The working group will
produce requirements appropriate for large Internet Service Provider
(ISP) and Enterprise Networks. This work is intended to refine
RFCxxxx.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Intended Audience . . . . . . . . . . . . . . . . . . . . 4
1.5 Format and Definition of Requirements . . . . . . . . . . 4
1.6 Applicability . . . . . . . . . . . . . . . . . . . . . . 5
1.7 Intended Use . . . . . . . . . . . . . . . . . . . . . . . 5
1.8 Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
2. Documents . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1 Standards Survey (info) . . . . . . . . . . . . . . . . . 10
2.2 In-Band management requirements (BCP) . . . . . . . . . . 10
2.3 Out-of-Band management requirements (BCP) . . . . . . . . 11
2.4 Filtering requirements (BCP) . . . . . . . . . . . . . . . 11
2.5 Event Logging Requirements document (BCP) . . . . . . . . 11
2.6 Configuration and Management Interface Requirements
(BCP) . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7 AAA requirements document (BCP) . . . . . . . . . . . . . 12
2.8 Documentation and Assurance requirements document (BCP) . 12
2.9 Miscellaneous requirements document (BCP) . . . . . . . . 12
2.10 Large ISP Operational Security Requirements Profile
(info) . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.11 Large Enterprise Operational Security Requirements
Profile (info) . . . . . . . . . . . . . . . . . . . . . 13
2.12 OPSEC Deliberation Summary document (info) . . . . . . . 13
3. Security Considerations . . . . . . . . . . . . . . . . . . 14
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1 Normative References . . . . . . . . . . . . . . . . . . . . 15
4.2 Non-normative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . 18
Jones, et al. Expires October 20, 2004 [Page 2]
Internet-Draft OpSec Framework April 2004
1. Introduction
1.1 Goals
The goal of the working group is to provide a clear, concise
documentation of operational security requirements for the
infrastructure of large IP networks, including routers and switches,
to equipment vendors, service providers, and network operators.
This framework document provides an overview of the work to be done
by the working group, and describes the documents to be produced in
this effort.
1.2 Motivation
Network operators need the appropriate feature sets and tools on
their infrastructure devices to ensure that they can effectively
deploy and manage their networks securely while maintaining the
ability to provide reliable service to their customers. Vendors need
guidelines on which security features and functionality are critical
for operators to be able to reach that goal.
The threats which network infrastructure devices are most susceptible
to encompass the following:
o unauthorized access to the device which can lead to portions of
the network infrastructure to be under malicious control
o denial of service attacks where the device is rendered incapable
of performing its intended function
o spoofing attacks where malicious packets can lead to network
traffic rerouting or network down-time
Many of these threats are described in detail in [RFC2196].
[RFC3013] recommends security services and procedures for ISPs and
provides a framework for discussion of security expectations. The
documents which will be described in this framework document will
complement these existing standards and will enumerate features which
are required to implement many of the policies and procedures
suggested in both.
1.3 Scope
The working group will produce requirements appropriate for:
o Internet Service Provider (ISP) Networks
o Enterprise Networks
The following classes of devices are excluded from the OPSEC working
group charter at this time, and are therefore outside of the scope of
Jones, et al. Expires October 20, 2004 [Page 3]
Internet-Draft OpSec Framework April 2004
this document:
o Wireless devices
o SOHO devices
o Security devices (firewalls, IDS, Authentication Servers)
o Hosts
The following are explicitly out of scope:
o general purpose hosts that do not transit traffic including
infrastructure hosts such as name/time/log/AAA servers, etc.,
o unmanaged devices,
o customer managed devices (e.g. firewalls, Intrusion Detection
System, dedicated VPN devices, etc.),
o SOHO (Small Office, Home Office) devices (e.g. personal
firewalls, Wireless Access Points, Cable Modems, etc.),
o confidentiality of customer data,
o integrity of customer data,
o physical security.
This means that while the requirements in the minimum profile (and
others) may apply, additional requirements have not be added to
account for their unique needs.
While the examples given are written with IPv4 in mind, most of the
requirements are general enough to apply to IPv6.
1.4 Intended Audience
There are two intended audiences: the network operator who selects,
purchases, and operates IP network equipment, and the vendors who
create these devices.
1.5 Format and Definition of Requirements
A separate document will be created for specific categories of
requirements. Each individual requirement will have the following
element:
Requirement (what)
The requirement describes a policy to be supported by the device.
For example, "The device MUST support secure channels that allow
in-band access to all management and configuration functions."
Requirements should not refer to specific technologies. It is
expected that requirements will change little over time.
Justification (why)
The justification tells why and in what context the requirement is
important.
Jones, et al. Expires October 20, 2004 [Page 4]
Internet-Draft OpSec Framework April 2004
For example, "Secure channels are important because they insure
confidentiality, and integrity. This is important in contexts
where management is performed in-band over networks with
potentially hostile users."
The justification is intended to give operators information needed
to determine the applicability of a requirement to their local
environment.
Examples (how)
Examples are intended to give examples of technology and standards
current at the time of writing that meet the requirement.
Examples of configuration and usage may also be given.
For example, "SSH provides access to management and configuration
functions via secure channels. One way to meet this requirement
might be to enable SSH for in-band management and to disable all
insecure in-band management mechanisms (e.g. telnet, SNMPv1,
etc.)"
It is expected that the choice of implementations to meet the
requirements will change over time. See [RFC3631] for a list of
some current mechanisms.
Warnings (if applicable)
The warnings list operational concerns, deviation from standards,
caveats, etc.
For example, "If SSH is chosen as the mechanism to provide secure
channels for remote management and configuration, then there are a
number of issues which must be considered including key
distribution and known vulnerabilities in various protocol
versions."
1.6 Applicability
These requirements are intended to give guidance on how best to
protect communications infrastructure. Service Providers, Network
Operators, and Equipment Suppliers are encouraged to study these
requirements, and prioritize the extent and manner in which they may
implement and/or deploy equipment supporting these requirements.
Decisions of whether or not to support a specific requirement are
intended to be left with the responsible organization (e.g., Service
Provider, Network Operator, or Equipment Supplier). Due to the
continuously evolving nature of security threats to networks, and due
to significant variations in the specific security threats and
requirements in different network environments, it is not appropriate
to mandate implementation of these requirements through legislation
or regulation, nor would any mandate be consistent with their intent.
1.7 Intended Use
It is anticipated that the requirements in these documents will be
Jones, et al. Expires October 20, 2004 [Page 5]
Internet-Draft OpSec Framework April 2004
used for the following purposes:
o as a checklist when evaluating networked products,
o to create profiles of different subsets of the requirements which
describe the needs of different devices, organizations, and
operating environments,
o to assist operators in clearly communicating their security
requirements,
o as high level guidance for the creation of detailed test plans.
o as guidance for vendors to make appropriate decisions for
engineering feature roadmaps.
1.8 Definitions
NOTE: THE FOLLOWING DEFINITIONS NEED TO BE DISCUSSED AT THE WORKING
GROUP
BCP [XXX Discuss @ Working Group]
Should we work on refining the definitions of "Current" and
"Practice" ? Does "current" mean that it's widely implemented,
that at least one vendor implements, other ??? Does "Practice"
mean "requirement". See [RFC2026].
Requirement [XXX Discuss @ Working Group]
See Section 1.5 for a definition and example of the term
"Requirement" as it is used in this document.
RFC 2119 Keywords [XXX Discuss @ Working Group]
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in [RFC2119].
NOTE: THE FOLLOWING DEFINITIONS WERE COPIED DIRECTLY FROM THE OPSEC
DRAFT AND IN SUBSEQUENT DRAFTS OF THE FRAMEWORK THEY MAY MOVE TO THE
SPECIFIC DRAFT THAT DEALS WITH THE TERM DEFINED. THEY ARE LEFT HERE
NOW TO INDICATE THAT THESE ARE AREAS THAT ARE LIKELY TO NEED
DISCUSSION AND DEFINITION IN THE SUBSEQUENT EFFORTS OF THE WORKING
GROUP.
Bogon.
A "Bogon" (plural: "bogons") is a packet with an IP source address
in an address block not yet allocated by IANA or the Regional
Internet Registries (ARIN, RIPE, APNIC...) as well as all
addresses reserved for private or special use by RFCs. See
[RFC3330] and [RFC1918].
CLI.
Several requirements refer to a Command Line Interface (CLI).
While this refers at present to a classic text oriented command
interface, it is not intended to preclude other mechanisms which
may meet all the requirements that reference "CLI".
Console.
Several requirements refer to a "Console". The model for this is
the classic RS232 serial port which has, for the past 30 or more
years, provided a simple, stable, reliable, well-understood and
nearly ubiquitous management interface to network devices. Again,
Jones, et al. Expires October 20, 2004 [Page 6]
Internet-Draft OpSec Framework April 2004
these requirements are intended primarily to codify the benefits
provided by that venerable interface, not to preclude other
mechanisms that meet all the same requirements.
Filter.
In this document, a "filter" is defined as a group of one or more
rules where each rule specifies one or more match criteria.
In-Band management.
"In-Band management" is defined as any management done over the
same channels and interfaces used for user/customer data.
Examples would include using SSH for management via customer or
Internet facing network interfaces.
High Resolution Time.
"High resolution time" is defined in this document as "time having
a resolution greater than one second" (e.g. milliseconds).
IP.
Unless otherwise indicated, "IP" refers to IPv4.
Management.
This document uses a broad definition of the term "management".
In this document, "management" refers to any authorized
interaction with the device intended to change its operational
state or configuration. Data/Forwarding plane functions (e.g.
the transit of customer traffic) are not considered management.
Control plane functions such as routing, signaling and link
management protocols and management plane functions such as remote
access, configuration and authentication are considered to be
management.
Martian.
Per [RFC1208] "Martian: Humorous term applied to packets that turn
up unexpectedly on the wrong network because of bogus routing
entries. Also used as a name for a packet which has an altogether
bogus (non-registered or ill-formed) Internet address." For the
purposes of this document Martians are defined as "packets having
a source address that, by application of the current forwarding
tables, would not have its return traffic routed back to the
sender." "Spoofed packets" are a common source of martians.
Note that in some cases, the traffic may be asymmetric, and a
simple forwarding table check might produce false positives. See
[RFC3704]
Out-of-Band (OoB) management.
"Out-of-Band management" is defined as any management done over
channels and interfaces that are separate from those used for
user/customer data. Examples would include a serial console
interface or a network interface connected to a dedicated
management network that is not used to carry customer traffic.
Jones, et al. Expires October 20, 2004 [Page 7]
Internet-Draft OpSec Framework April 2004
Open Review.
"Open review" refers to processes designed to generate public
discussion and review of technical solutions such as data
communications protocols and cryptographic algorithms with the
goals of improving and building confidence in the final solutions.
For the purposes of this document "open review" is defined by
[RFC2026]. All standards track documents are considered to have
been through an open review process.
It should be noted that organizations may have local requirements
that define what they view as acceptable "open review". For
example, they may be required to adhere to certain national or
international standards. Such modifications of the definition of
the term "open review", while important, are considered local
issues that should be discussed between the organization and the
vendor.
It should also be noted that section 7 of [RFC2026] permits
standards track documents to incorporate other "external standards
and specifications".
Service.
A number of requirements refer to "services". For the purposes of
this document a "service" is defined as "any process or protocol
running in the control or management planes to which non-transit
packets may be delivered". Examples might include an SSH server,
a BGP process or an NTP server. It would also include the
transport, network and link layer protocols since, for example, a
TCP packet addressed to a port on which no service is listening
will be "delivered" to the IP stack, and possibly result in an
ICMP message being sent back.
Secure Channel.
A "secure channel" is a mechanism that ensures end-to-end
integrity and confidentiality of communications. Examples include
TLS [RFC2246] and IPsec [RFC2401]. Connecting a terminal to a
console port using physically secure, shielded cable would provide
confidentiality but possibly not integrity.
Single-Homed Network.
A "single-homed network" is defined as one for which
* There is only one upstream connection
* Routing is symmetric.
See [RFC3704] for a discussion of related issues and mechanisms
for multihomed networks.
Spoofed Packet.
A "spoofed packet" is defined as a packet that has a source
address that does not correspond to any address assigned to the
system which sent the packet. Spoofed packets are often "bogons"
or "martians".
Jones, et al. Expires October 20, 2004 [Page 8]
Internet-Draft OpSec Framework April 2004
Secure Network
For the purposes of these documents, a secure network is one in
which:
* The network keeps passing legitimate customer traffic
(availability).
* Traffic goes where it is supposed to go, and only where it is
supposed to go (availability, confidentiality).
* The network elements remain manageable (availability).
* Only authorized users can manage network elements
(authorization).
* There is a record of all security related events
(accountability).
* The network operator has the necessary tools to detect and
respond to illegitimate traffic.
Jones, et al. Expires October 20, 2004 [Page 9]
Internet-Draft OpSec Framework April 2004
2. Documents
The following is a list of documents to be produced by OPSEC working
group. Each document is intended to cover an area important to
secure operation of large network infrastructure.
2.1 Standards Survey (info)
Overview
This document provides an overview of other efforts in developing
standards, guidelines, best practices, or other information
intended to facilitate improvement in network security. Any
effort which is known, such as the ANSI T1.276, the NRIC V "Best
Practices", ITU-T M.3016 and X.805, the T1S1 effort on securing
signalling will be included. The intent is to provide a clear
understanding of which efforts are complementary and/or
contradictory such that any efforts of future cross-certification
of standards may be facilitated.
Security Considerations
Any contradictory security requirements from varying standards
bodies would seriously impact operator or vendor understanding of
which features and functionalities are the most effective to
deploy and operate secure networks. This documented survey will
help to ensure that there is a consistent set of product
requirements to follow.
2.2 In-Band management requirements (BCP)
Overview
Although there are known security issues with in-band management,
there are many situations where in-band management makes sense, is
used, and/or is the only option. The features recommended in this
document will provide for a more secure means of using any in-band
management functionality.
Security Considerations
Although in-band management has the advantage of lower cost (no
extra interfaces or lines), it has significant security
disadvantages:
* Saturation of customer lines or interfaces can make the device
unmanageable unless out-of-band management resources have been
reserved
* Since public interfaces/channels are used, it is possible for
attackers to directly address and reach the device and to
attempt management functions.
* In-band management traffic on public interfaces may be
intercepted, however this would typically require a significant
compromise in the routing system.
* Public interfaces used for in-band management may become
unavailable due to bugs (e.g. buffer overflows being
exploited) while out-of-band interfaces (such as a serial
Jones, et al. Expires October 20, 2004 [Page 10]
Internet-Draft OpSec Framework April 2004
console device) remain available
The requirements from this document are meant to provide the means
of securing in-band management traffic.
2.3 Out-of-Band management requirements (BCP)
Overview
This document will describe requirements related to out of band
management of networked devices.
Security Considerations
Out-of-band management often provides a more secure means of
managing networked devices. To ensure that all devices have the
appropriate support, this document will set requirements as to
what functionality is needed to effectively use out-of-band
management.
2.4 Filtering requirements (BCP)
Overview
This document will describe requirements related to stateless
filtering requirements for network elements providing transit
service at OSI layers 2 and 3.
Security Considerations
Filtering is an important security functionality to permit or deny
forwarding of traffic, or to specify special treatment of packets,
depending on layer 2 or layer 3 header and forwarding information.
It provides a basic means of implementing policies, such as
policies that specify which traffic is allowed and which is not,
and policies which specify special treatment such as setting CoS,
rate limiting, or packet copying. It also provides a basic tool
for responding to malicious traffic.
2.5 Event Logging Requirements document (BCP)
Overview
[Ed. The basic questions here are "what gets logged", "how does
it get logged", "what are the security issues". There is work in
progress (syslog) for the last two that can be cited. The "what
gets logged" question needs work]
This document will describe the recommended features when logging
network device traffic and anomalies. The goal is to make it
possible to correlate logging information from varying systems and
making sure that logged information is useful and effective.
Security Considerations
Logging data provides a means for detecting malicious behavior.
The logged information can also be used as evidence in legal
prosecution cases against illegal network access and device
compromises. Ineffective logging practices due to inconsistent
functionality in many devices make it hard to get effective data.
This document will help provide consistent logging functionality
for more effective auditing. It will also point to privacy or
Jones, et al. Expires October 20, 2004 [Page 11]
Internet-Draft OpSec Framework April 2004
legal considerations when logging/monitoring user activity.
2.6 Configuration and Management Interface Requirements (BCP)
Overview
This document lists the security requirements for interfaces which
allow for configuring and managing the network device. In most
cases, this currently involves some sort of command line interface
(CLI) and configuration files. It may be possible to meet these
requirements with other mechanisms, for instance SNMP or a
script-able HTML interface that provides full access to management
and configuration functions. In the future, there may be others
(e.g. XML based configuration).
Security Considerations
The interfaces used to manage and configure network elements need
to be effectively secured to avoid a malicious user from being
able to logically gain illegal access. In the past, many security
vulnerabilities have been discovered, especially with SNMP and
HTTP access to devices. These recommendations will help the user
and vendor community mitigate any known risks in this area.
2.7 AAA requirements document (BCP)
Overview
This document will list the requirements for centralized
authentication, authorization and accounting functionality.
Security Considerations
Keeping track of who has access to network devices is critical to
any secure infrastructure. Mechanisms to provide authorized
access upon successful authentication and also keeping track of
what was done can provide important information in case of a
device compromise.
2.8 Documentation and Assurance requirements document (BCP)
Overview
These requirements will list information which should be
documented that will assist operators in evaluating and securely
operating a device.
Security Considerations
Devices many times have default behavior which can cause a severe
security vulnerability. Knowing which services are enabled by
default or which commands impact other default behavior is
essential knowledge that is necessary to effectively mitigate
security risks.
2.9 Miscellaneous requirements document (BCP)
Overview
Jones, et al. Expires October 20, 2004 [Page 12]
Internet-Draft OpSec Framework April 2004
This document will describe requirements which do not fit into any
of the other documents, and which are brief enough that they don't
justify their own document, but which are important enough that
they should be documented.
2.10 Large ISP Operational Security Requirements Profile (info)
Overview
This document will provide a profile specifying which of the
requirements outlined in the set of documents described above are
most applicable to large Internet Service Providers offering
transit service.
2.11 Large Enterprise Operational Security Requirements Profile (info)
Overview
This document will provide a profile specifying which of the
requirements outlined in the set of documents described above are
most applicable to large Enterprise networks.
2.12 OPSEC Deliberation Summary document (info)
Overview
This document will provide a summary of discussions that have
taken place within the OPsec working group. The intent is to
document ideas that were "left on the cutting room floor" in order
to provide a possible starting point for future work.
Jones, et al. Expires October 20, 2004 [Page 13]
Internet-Draft OpSec Framework April 2004
3. Security Considerations
Security is the entire focus of this document.
Jones, et al. Expires October 20, 2004 [Page 14]
Internet-Draft OpSec Framework April 2004
4. References
4.1 Normative References
[RFC1208] Jacobsen, O. and D. Lynch, "Glossary of networking terms",
RFC 1208, March 1991.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and
E. Lear, "Address Allocation for Private Internets", BCP
5, RFC 1918, February 1996.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, September
1997.
[RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A.
and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246,
January 1999.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC3013] Killalea, T., "Recommended Internet Service Provider
Security Services and Procedures", BCP 46, RFC 3013,
November 2000.
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September
2002.
[RFC3631] Bellovin, S. and J. Schiller, "Security Mechanisms for the
Internet", RFC 3631, December 2003.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
4.2 Non-normative References
[I-D.savola-bcp38-multihoming-update]
Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", draft-savola-bcp38-multihoming-update-03 (work
Jones, et al. Expires October 20, 2004 [Page 15]
Internet-Draft OpSec Framework April 2004
in progress), December 2003.
[Schneier]
Schneier, B., "Applied Crytography, 2nd Ed., Publisher
John Wiley & Sons, Inc.", 1996.
Authors' Addresses
George M. Jones
The MITRE Corporation
7515 Colshire Drive, M/S WEST
McLean, Virginia 22102-7508
U.S.A.
Phone: +1 703 488 9740
EMail: gmjones@mitre.org
Ross Callon
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
U.S.A.
Phone: +1 978 692 6724
EMail: rcallon@juniper.net
Merike Kaeo
Double Shot Security
520 Washington Blvd. #363
Marina Del Rey, CA 90292
U.S.A.
Phone: +1 310 866 0165
EMail: kaeo@merike.com
Jones, et al. Expires October 20, 2004 [Page 16]
Internet-Draft OpSec Framework April 2004
Appendix A. Acknowledgments
The authors gratefully acknowledge the contributions of:
o Acknowledgments to be determined.
o The MITRE Corporation for supporting development of this document.
NOTE: The author's affiliation with The MITRE Corporation is
provided for identification purposes only, and is not intended to
convey or imply MITRE's concurrence with, or support for, the
positions, opinions or viewpoints expressed by the editor.
o This listing is intended to acknowledge contributions, not to
imply that the individual or organizations approve the content of
this document.
o Apologies to those who commented on/contributed to the document
and were not listed.
Jones, et al. Expires October 20, 2004 [Page 17]
Internet-Draft OpSec Framework April 2004
Intellectual Property Statement
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.
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
Internet Society.
Jones, et al. Expires October 20, 2004 [Page 18]