Network Working Group S. Hanna
Internet-Draft Juniper Networks
Expires: June 24, 2006 T. Hardjono
Signacert Inc.
S. Thomson
Cisco Systems
December 21, 2005
Network Endpoint Assessment (NEA) Problem Statement
draft-thomson-nea-problem-statement-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 June 24, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Network endpoint assessment (NEA) is a system that enables the
network to learn the posture (state) of an endpoint device, and
optionally use that information to influence a network admission
decision. Posture information may include information about the OS
and security applications running on the endpoint. This document
Hanna, et al. Expires June 24, 2006 [Page 1]
Internet-Draft NEA Problem Statement December 2005
describes the problem network endpoint assessment is intending to
address, and identifies interfaces that are candidates for
standardization.
Requirements Language
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 RFC 2119 [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 6
5.1. Wired LAN access . . . . . . . . . . . . . . . . . . . . . 6
5.2. Wireless LAN Access . . . . . . . . . . . . . . . . . . . 6
5.3. Remote access VPN . . . . . . . . . . . . . . . . . . . . 6
5.4. Gateway Access . . . . . . . . . . . . . . . . . . . . . . 7
6. Components and Interfaces . . . . . . . . . . . . . . . . . . 7
6.1. Relationship to EAP and AAA Architecture . . . . . . . . . 8
6.2. Components . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2.1. NEA Agent . . . . . . . . . . . . . . . . . . . . . . 8
6.2.2. Network enforcer . . . . . . . . . . . . . . . . . . . 9
6.2.3. NEA server . . . . . . . . . . . . . . . . . . . . . . 9
6.3. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 11
6.3.1. Posture Attribute interface (IF-PA) . . . . . . . . . 11
6.3.2. Posture Broker Interface (IF-PB) . . . . . . . . . . . 11
6.3.3. Posture Transport Interface (IF-PT) . . . . . . . . . 11
6.3.4. Network Access Enforcement Interface (IF-NAE) . . . . 11
6.3.5. Other . . . . . . . . . . . . . . . . . . . . . . . . 11
6.4. System Flow . . . . . . . . . . . . . . . . . . . . . . . 12
7. Scope of Standardization . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9.1. Secure channel between the NEA Agent Broker and Server
Broker . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.2. Authorization for Plug-in/Broker interaction . . . . . . . 13
9.3. Self-Integrity of the NEA Agent and NEA Server . . . . . . 14
9.4. Protection of parameters exchanged across Interfaces . . . 14
9.5. Identity authentication of communicating end-points . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
11. Normative References . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Hanna, et al. Expires June 24, 2006 [Page 2]
Internet-Draft NEA Problem Statement December 2005
1. Introduction
Network endpoint assessment (NEA) is a system that enables the
network to learn the posture (state) of an endpoint device, and
optionally use that information to influence a network admission
decision. Endpoint posture may include information about the
operating system as well as information about security applications
running on the endpoint such as anti-virus software, personal
firewalls and host intrusion protection systems.
An organization may use posture information for several purposes
including monitoring and enforcing compliance of endpoints to the
organization's security policy, and supplementing and updating
information in asset tracking databases.
The document describes the problem network endpoint assessment is
intending to address, defines terminology and concepts, and
identifies interfaces that are candidates for standardization.
Note that this document is not intended to define a new architecture
or framework for network endpoint assessment. There are already
several existing architectures for this purpose. The network
endpoint assessment effort aims only to identify common interfaces
that are used in these architectures, and define standard protocols
that can be used by the existing architectures to reduce duplication
and achieve interoperability.
2. Terminology
Endpoint: An endpoint is a host connected to the network. This broad
definition includes (but is not limited to) desktop or laptop
computers, servers, mobile phones, printers.
Posture: Posture refers to the state of an endpoint as it pertains to
an organization's security policy. Endpoint state may include
knowledge about the types of hardware and software installed and
their configurations, e.g. OS name and version, application patch
levels, and anti-virus signature file version.
NEA agent: The NEA agent is a software component on the endpoint that
requests access to the network. The NEA agent comprises three
logical components: NEA agent plug-in, NEA agent broker and Network
access requestor.
Network enforcer: The Network enforcer is a network device that
controls endpoint access to the upstream network. It implements
authorization decisions from the Network access authority.
Hanna, et al. Expires June 24, 2006 [Page 3]
Internet-Draft NEA Problem Statement December 2005
NEA server: The NEA server is a server that assesses the posture of
an endpoint device and provides network authorization decisions. The
NEA server comprises three logical components: NEA posture server,
NEA server broker and Network Access Authority.
NEA agent plug-in: A NEA agent plug-in is the component of the NEA
agent that is responsible for collecting and maintaining posture
information about the endpoint device. There may be multiple NEA
agent plug-ins on an endpoint device each targeted at a particular
security application from a particular vendor.
NEA agent broker: A NEA agent broker is the component of the NEA
agent that aggregates posture information from multiple NEA agent
plug-ins.
Network access requestor: The Network access requestor is the
component of the NEA agent responsible for requesting access to the
network.
Network access authority: The Network access authority is the
component of the NEA server that authorizes endpoints based on a
number of criteria including the identity of an endpoint machine
and/or user as well as the results of posture assessment
NEA server broker: A NEA server broker is the component of the NEA
server that aggregates posture information from multiple NEA posture
servers.
NEA posture server: A NEA posture server is the logical component of
the NEA server that assesses posture information from a NEA agent
plug-in and determines the result of the assessment. There may be
multiple NEA posture servers each targeted at a particular security
application from a particular vendor.
3. Problem Statement
Viruses and worms are a top cause of financial loss due to disruption
of business activities and loss of employee productivity. Endpoints
are vulnerable to such attacks and, once infected, may in turn infect
others. To protect against infection (and re-infection), corporate
security policy often requires that hosts run an IT-specified OS
configuration and have certain security applications enabled, e.g.
anti-virus software, host intrusion protection systems, personal
firewalls, and patch management software.
However, ensuring compliance of all endpoints to corporate security
policy is still time-consuming and difficult. Not all endpoints are
Hanna, et al. Expires June 24, 2006 [Page 4]
Internet-Draft NEA Problem Statement December 2005
managed by a corporation's IT organization, e.g. lab assets, guest
machines. Even for assets that are managed, they may not receive
updates in a timely fashion because they are not permanently attached
to the corporate network, e.g. laptops. Also, for organizations that
attempt to keep track of their assets, inventory databases tend to be
incomplete and out-of-date.
The purpose of network endpoint assessment technology is to allow the
network to supplement the role that security applications already
play in protecting endpoints. First, the network is able to detect
when an endpoint accesses the network, thus providing an opportunity
to assess an endpoint both prior to granting network access as well
as while the endpoint remains connected to the network. Second, the
network can be used to enforce compliance. Endpoints that are not
compliant with security policy and are considered a risk to the
network may be given restricted access until remediated.
Today, most network access technologies, e.g. 802.1x, PPP and IPSEC
VPN, authenticate an endpoint prior to granting network access, and
if authentication succeeds, allow an authorization decision to be
made based on the identity of the endpoint. Common interoperable
standards should be defined for assessing the posture of an endpoint
device in addition to performing authentication as part of network
access control.
4. Goals
The goals of network assessment technology are to support the
following:
o Support assessment of endpoints across a range of network access
technologies, leveraging existing technology to the extent
possible
o Support authorization decisions based on authentication of user or
endpoint device, assessment of the state of the endpoint device,
or both
o Support endpoint assessment at various locations in the network
i.e. at a L2 hop or a L3 hop, both of which may be a single hop or
multiple hops away from the endpoint.
o Support endpoint assessment at possibly multiple hops on a path
e.g. at both a L2 and a L3 hop
o Support network isolation of non-compliant endpoints from
compliant endpoints for remediation or other purposes
Hanna, et al. Expires June 24, 2006 [Page 5]
Internet-Draft NEA Problem Statement December 2005
o Support endpoint re-assessment when state of endpoints change, or
rules in the NEA server change
o Enable integration of 3rd-party security applications so that one
or more applications can assess the posture of an endpoint and the
aggregate of all results can be used in network admission
decisions.
o Support endpoints with a NEA agent and without an agent
5. Deployment Scenarios
Network assessment has been targeted primarily at enterprise
deployment scenarios to date.The deployment scenarios include:
5.1. Wired LAN access
In this deployment scenario, network admission control would
typically take place at the first L2 hop from the endpoint i.e. a
switch port. However, there are cases where the first L2 device may
not support network endpoint assessment for some reason, and network
endpoint assessment may happen behind the first hop, e.g. a switch
behind a wireless access point.
Wired LAN access deployment scenarios may need to support single or
multiple hosts per switch port. Deployment scenarios with multiple
hosts per port include IP phones + PC, or multiple PCs connected
behind a hub.
802.1x is an example of a standards-based network access technology
that supports access control based on authentication for a single
host per port in first L2 hop deployment scenarios.
5.2. Wireless LAN Access
In this deployment scenario, network admission control would
typically take place at the first L2 hop from the endpoint i.e. a
wireless access point. Wireless LAN access supports multiple hosts
per wireless access point.
802.11 is a standards-based network access technology that supports
wireless access control based on authenticating the endpoint.
5.3. Remote access VPN
In this deployment scenario, network admission control is done at the
VPN concentrator that acts as the gateway between remote users and
Hanna, et al. Expires June 24, 2006 [Page 6]
Internet-Draft NEA Problem Statement December 2005
access to the enterprise network.
IPSEC VPN and SSL VPN are example of network access technologies that
support remote access VPN deployment scenarios.
5.4. Gateway Access
In this deployment scenario, network admission control is enforced at
a L3 boundary in a distributed campus network. The L3 boundary may
be one or more L3 hops away from the endpoint.
This deployment scenario may be used during the transition period
while an organization gradually upgrades network equipment to support
network endpoint assessment. In some cases, the technology may not
be available immediately for first-hop L2 or L3 deployments and a
general-purpose gateway deployment e.g. at a router behind a VPN
concentrator, may be a reasonable first step.
This deployment scenario may also be used between network security
domains e.g. at the border between a less trusted/managed branch
office and main campus, at the border between main campus or a
visitor site and access to the Internet, at the border between
extranet and intranet, and on access to protected servers in a data
center.
It follows from this deployment scenario that there may be multiple
network enforcers on any path that an endpoint may use in a network,
thus resulting in it being authorized more than once. It is also
possible that different posture rules may be assessed at different
network locations and a different authorization decision made.
6. Components and Interfaces
Figure 1 shows the components of the NEA system and identifies
specific interfaces.
Hanna, et al. Expires June 24, 2006 [Page 7]
Internet-Draft NEA Problem Statement December 2005
|-------------| |----------------|
| NEA Plug-in | <-------IF-PA-------> | NEA Posture |
| | | Server |
|-------------| |----------------|
|-------------| |----------------|
| NEA Agent | <-------IF-PB-------> | NEA Server |
| Broker | | Broker |
|--------- ---| |----------------|
|-------------| <------IF-PT-------> |----------------|
| | | |
| Network | |--------| | Network |
| Access | |Network | | Access |
| Requestor | |Enforcer| <-IF-NAE-> | Authority |
|-------------| |--------| |----------------|
NEA AGENT NEA SERVER
Figure 1: NEA Components and Interfaces
6.1. Relationship to EAP and AAA Architecture
Network endpoint assessment technology can build on the EAP and AAA
architectures, so that existing technologies can be used to the
extent possible including EAP, Radius, 802.1x, PPP, IPSEC VPN.
6.2. Components
6.2.1. NEA Agent
The NEA Agent resides on an endpoint device and comprises the
following components:
o NEA Agent Plug-in
o NEA Agent Broker
o Network Access Requestor
6.2.1.1. NEA Agent Plug-in
The NEA agent plug-in is software that provide posture information
about the endpoint device to the NEA agent broker. There may be many
plug-ins in an agent, one per vendor and application type. Examples
of plug-ins include a host plug-in that provides information about
the OS and patch levels, anti-virus plug-in that provides information
Hanna, et al. Expires June 24, 2006 [Page 8]
Internet-Draft NEA Problem Statement December 2005
about the anti-virus application, firewall plug-in that provides
information about the configuration of the personal firewall.
An agent plug-in is responsible for:
o Receiving and responding to requests for posture information on a
per vendor and application type basis
o Receiving a notification of the result of the posture assessment
and information any actions to perform e.g. URL of a remediation
server
o Indicating when the posture of the host has changed
6.2.1.2. NEA Agent Broker
The NEA agent broker aggregates posture information from multiple NEA
agent plug-ins. The NEA agent broker is responsible for:
o Maintaining a record of agent plug-ins
o Multiplexing and demultiplexing posture messages between the NEA
server and the relevant plug-ins
o Determining from plug-ins when posture has changed and triggering
re-assessment where supported by the underlying transport
o Providing user notifications
6.2.1.3. Network access requestor
The Network access requestor is responsible for communicating with
the NEA server (likely via the enforcer) to transport the necessary
information to gain access to the network and for subsequent re-
assessment.
6.2.2. Network enforcer
The Network enforcer is a network device that controls access of
endpoints to the upstream network. The NEA enforcer implements
authorization decisions from the Network access authority.
6.2.3. NEA server
The NEA server comprises the following logical components (which may
or may not be co-located on a single server):
Hanna, et al. Expires June 24, 2006 [Page 9]
Internet-Draft NEA Problem Statement December 2005
o Network access authority
o NEA server broker
o NEA server plug-in
6.2.3.1. Network access authority
The Network access authority is responsible for authorizing endpoints
based on a number of criteria including the identity of an endpoint
and/or user as well as the results of posture assessment
6.2.3.2. NEA server broker
The NEA server broker aggregates posture information from potentially
multiple server plug-ins. Responsibilities of the NEA server broker
include:
o Maintaining a record of server plug-ins
o Multiplexing and demultiplexing posture messages between the NEA
agent and the relevant plug-ins
o Aggregating posture assessment results from all plug-ins into an
overall system result
o Triggering posture reassessment where supported
6.2.3.3. NEA posture server
A NEA posture server is a server that is responsible for assessing
information from the corresponding NEA agent plug-in and determining
the result of the assessment. There may be multiple posture servers
each targeted at a particular security application from a particular
vendor.
A NEA posture server is responsible for the following:
o Requesting and receiving posture information from a particular NEA
agent plug-in
o Assessing the posture of the NEA agent plug-in and providing a
result to the NEA agent plug-in along with any information on
remediation actions to be taken
o Indicating to the NEA server broker when posture reassessment may
be needed
Hanna, et al. Expires June 24, 2006 [Page 10]
Internet-Draft NEA Problem Statement December 2005
6.3. Interfaces
6.3.1. Posture Attribute interface (IF-PA)
The IF-PA is a protocol between the NEA agent plug-in and the NEA
posture server. The interface is used to pass information about the
posture of a plug-in, the results of the assessment and information
needed for remediation.
6.3.2. Posture Broker Interface (IF-PB)
The IF-PB is a protocol that carries aggregated posture information
between all requested plug-ins on an endpoint and the corresponding
posture servers. This protocol also carries the overall system
posture result from the NEA server broker to the agent broker.
6.3.3. Posture Transport Interface (IF-PT)
The IF-PT is the transport protocol between the Network access
requestor and the Network access authority that carries the IF-PB
protocol. In network endpoint assessment systems that use EAP, this
interface would be an EAP method running over typically a combination
of underlying network transports, e.g. EAP over 802.1x, EAP over
Radius.
6.3.4. Network Access Enforcement Interface (IF-NAE)
The IF-NAE is the protocol between the Network enforcer and Network
access authority used to carry network access decisions between the
Network enforcer and the Network access authority.
6.3.5. Other
Interfaces also exist between the logical components that make up the
NEA agent and the NEA server themselves. For example, an interface
exists between the plug-in and broker components on the agent, as
well as between the broker and network access requestor components.
Similarly, an interface exists between the posture server and broker
components on the NEA server as well as the broker and network access
authority components.
The interfaces on the NEA agent are likely local APIs. This may be
true on the NEA server as well, but deployments where components are
not co-located are also possible. Since these interfaces do not fall
clearly within the purview of the IETF, standardization efforts are
initially focused on the interfaces explicitly identified above.
Standardization of some of these other interfaces may be called for
in the future.
Hanna, et al. Expires June 24, 2006 [Page 11]
Internet-Draft NEA Problem Statement December 2005
6.4. System Flow
TBD.
7. Scope of Standardization
Interfaces that are candidates for standardization in the IETF
include the following :
o Posture attributes interface (IF-PA): This interface can be
defined independently of the underlying transport interfaces,
while keeping in mind performance and other constraints imposed by
the underlying protocols. Many of the posture attributes will be
vendor-specific and need only be understood by the corresponding a
plug-in and its associated posture server. However. there are
common attributes that would benefit from standardization.
o Posture broker interface (IF-PB): This interface is also largely
independent of the underlying transport, although it should be
defined in such a way that it can be used in posture transport
interfaces that are likely to be used, such as EAP tunneling
methods based on TLS e.g. by using the same TLV framing that is
already used in these methods today.
o Posture transport interface (IF-PT): While different posture
transport interfaces may be used to support network endpoint
assessment, one likely choice of transport is EAP. The benefits
of EAP are that it can be used to meet a range of deployment
scenarios since it is designed to be independent of the underlying
network transport, and is extensible to supporting both
authentication and posture assessment in making a network access
decision. Standardization of certain EAP methods for
authentication is the proposed charter of the EMU WG. The need to
support posture assessment in addition to authentication may place
additional requirements on the EAP methods that need to be
standardized. In particular, standardization of tunnel EAP
methods is a high priority. Also, there is no standard EAP
transport to support gateway and other "multi-hop" deployment
scenarios as defined in this document. The PANA WG has proposed a
specification of EAP over an IP transport, although not explicitly
for this use case. Non-standardized protocols have been designed
and used for this purpose.
o Network access enforcement interface (IF-NAE): Existing standards
exist including Radius and Diameter. The Radext WG has the
charter to standardize Radius extensions. Its not clear that NEA
would require any extensions that fall outside of the scope of the
Hanna, et al. Expires June 24, 2006 [Page 12]
Internet-Draft NEA Problem Statement December 2005
existing charter of that WG.
As mentioned earlier, the remaining interfaces that have been
identified will likely not be within the scope of standardization
efforts, at least not initially. This could be revised in future.
8. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
9. Security Considerations
A NEA system includes a number of functional components and
interfaces, and thus there are a number of security aspects
pertaining to the system as a whole which need to be highlighted.
Some of these are discussed in the following sections.
9.1. Secure channel between the NEA Agent Broker and Server Broker
The NEA Agent Broker needs to be able to communicate the posture
information regarding the NEA Agent to the NEA Server Broker with
communications integrity and confidentiality. One possible avenue
towards establishing this secure channel (at the peer layer of the
NEA Agent Broker and Server Broker) is to establish it end-to-end
between Network Access Requestor (NAR) and the Network Access
Authority (NAA). This end-to-end secure channel would prevent any
intermediate entity, including the Network Enforcer from gaining
access to the posture information. The exact implementation of this
secure channel is dependent on the domain of application and network
configuration.
9.2. Authorization for Plug-in/Broker interaction
There is a functional separation between the NEA Agent Plug-in and
the NEA Agent Broker (at the NEA Agent side) and also between NEA
Posture Server and the NEA Server Broker (at the NEA Server side).
It is important that a NEA Agent Broker be allowed to communicate
with only the authorized NEA Agent Plug-ins. Similarly, the NEA
Server Broker should only communicate with authorized NEA Posture
Server. Recall that the NEA Agent Plug-in is software that provides
posture information about the endpoint device to the NEA Agent
Broker. Note that there may be many plug-ins in an agent, one per
vendor and application type. Without protection, bogus NEA Agent
Hanna, et al. Expires June 24, 2006 [Page 13]
Internet-Draft NEA Problem Statement December 2005
Plug-in (NEA Posture Server) can open communications with the NEA
Agent Broker (NEA Server Broker), thereby opening the possibility of
a Denial-of-Service attack (at the very least) against the NEA Agent
Broker and NEA Server Broker respectively.
9.3. Self-Integrity of the NEA Agent and NEA Server
The trustworthiness of the posture information being reported by the
NEA Agent to the NEA Server is dependent on and is only as good as
the self-integrity of the NEA Agent and NEA Server respectively. If
malicious code or other malware are present in the NEA Agent actively
modifying posture information being communicated by the NEA Agent,
the NEA Server may be basing its decision-making on inaccurate or
bogus posture information. Thus, it is important that both the NEA
Agent and the NEA Server are protected against attacks that illegally
modify the system configurations and system components of these
entities.
9.4. Protection of parameters exchanged across Interfaces
An important aspect of the NEA sytem is the protection of parameters
being communicated between the various interfaces defined in the
architecture. Examples of the parameters being exchanged include,
but not limited to, state change notifications between the NEA Agent
Broker and NEA Agent Plug-in, state change notifications between the
NEA Server Broker and NEA Posture Server, the parameters and messages
exchanged between two peer entities (on the NEA Agent and NEA Server
respectively) across IF-PA and IF-PB, and in general parameters and
messages exchanged across interfaces IF-PT, and IF-NAE.
9.5. Identity authentication of communicating end-points
In order for the NEA Server to accept access requests and posture
information being reported to by the NEA Agent, the NEA Server may
need to authenticate the NEA Agent in some manner. Similarly, within
some network environments there may be the requirement that the NEA
Agent also authenticate the NEA Server with whom it is communicating.
Although the process of evaluating an access request may combine
together the notion of authentication and integrity state evaluation
(through posture information), it is important from a security
perspective and useful from a good engineering practices perspective
to be able to separate end-point authentication (includling both
machine and user authentication) from end-point posture assessment.
10. Acknowledgements
TBD
Hanna, et al. Expires June 24, 2006 [Page 14]
Internet-Draft NEA Problem Statement December 2005
11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Hanna, et al. Expires June 24, 2006 [Page 15]
Internet-Draft NEA Problem Statement December 2005
Authors' Addresses
Steve Hanna
Juniper Networks
shanna@juniper.net
Thomas Hardjono
Signacert Inc.
thardjono@signacert.com
Susan Thomson
Cisco Systems
sethomso@cisco.com
Hanna, et al. Expires June 24, 2006 [Page 16]
Internet-Draft NEA Problem Statement December 2005
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 (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hanna, et al. Expires June 24, 2006 [Page 17]