Internet DRAFT - draft-ohba-hokeyp-preauth-ps
draft-ohba-hokeyp-preauth-ps
Network Working Group Y. Ohba
Internet-Draft Toshiba
Expires: October 3, 2006 A. Dutta
Telcordia
S. Sreemanthula
Nokia
Apr 2006
Pre-authentication Problem Statement
draft-ohba-hokeyp-preauth-ps-00
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 October 3, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes a pre-authentication problem statement. This
document is used as the basis of the pre-authentication part of the
charter of a potential IETF working group on handover keying and pre-
authentication.
Ohba, et al. Expires October 3, 2006 [Page 1]
Internet-Draft Pre-authentication Problem Statement Apr 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Direct Pre-authentication . . . . . . . . . . . . . . . . 8
3.2. Indirect Pre-authentication . . . . . . . . . . . . . . . 8
4. AAA Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Out-of-scope Issues . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Performance Requirements . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21
Ohba, et al. Expires October 3, 2006 [Page 2]
Internet-Draft Pre-authentication Problem Statement Apr 2006
1. Introduction
When a mobile during an active communication session moves from one
access network to another access network and changes its point of
attachment it is subjected to disruption in the continuity of service
because of the associated handover operation. During the handover
process, when the mobile changes its point-of-attachment in the
network, it may end up communicating using its second interface in
the new network, change its subnet or administrative domain it is
connected to. A complete description of the types of handover based
on the movement type is documented in [I-D.ohba-mobopts-
heterogeneous-requirement]. We provide in Appendix A some
performance requirement that are needed to support an interactive
real-time communication such as VoIP and thus can serve as the
guidelines for handover optimization.
Handover often requires authorization for acquisition or modification
of resources assigned to a mobile and the authorization needs
interaction with a central authority in a domain. In many cases an
authorization procedure during a handover procedure follows an
authentication procedure that also requires interaction with a
central authority in a domain. If the handover involves inter-domain
mobility without any roaming or trust relationship between the
domains, then the delay introduced due to a full authentication and
authorization procedure adds to the handover latency and consequently
affects the ongoing multimedia sessions. The authentication and
authorization procedure may include EAP authentication [RFC3748]
where an AAA server may be involved in EAP messaging during the
handover. Depending upon the type of architecture, in some cases the
AAA signals traverse all the way to the AAA server in the home domain
of the mobile as well before the network service is granted to the
mobile in the new network. As an example a combination of EAP-based
authentication and authorization may take up to 5 sec [georgiades].
Real-time communication and interactive traffic such as VoIP is very
sensitive to the delay and thus cannot tolerate this amount of delay.
Thus it is necessary to reduce the delay due to authentication,
authorization and AAA related key transfer. Thus it is desirable
that interactions between the mobile and AAA servers must be avoided
or be reduced during the handover.
This draft discusses pre-authentication, a handover optimization
method that is based on executing EAP between a mobile node and a
target authenticator via the serving authenticator before the mobile
node handovers to the target authenticator.
1.1. Specification of Requirements
In this document, several words are used to signify the requirements
Ohba, et al. Expires October 3, 2006 [Page 3]
Internet-Draft Pre-authentication Problem Statement Apr 2006
of the specification. These words are often capitalized. 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].
Ohba, et al. Expires October 3, 2006 [Page 4]
Internet-Draft Pre-authentication Problem Statement Apr 2006
2. Problem Statement
Basic mechanism of handover is a two step procedure involving i)
network selection procedure to determine the appropriate candidate
network point of attachment and ii) handover or setting up of L2 and
L3 connectivity to the target network point of attachment.
Currently, security mechanisms for authentication and authorization
is performed as part of the second step directly with the target
network. Experimental studies with network handovers indicate that
the latency introduced due to the security mechanisms is not
acceptable for real time communications. For example, in basic IEEE
802.11b based wireless networks, the security mechanism involves
performing a new IEEE 802.1x message exchange with the authenticator
in the target AP to initiate an EAP exchange to the authentication
server. Following a successful authentication, a four-way handshake
with the wireless station derives a new set of the session keys for
use in data communications. This mechanism is same as the initial
setup to the AP with no particular optimizations for the handover
scenario. The handover latency component introduced by this security
mechanism has proven to be larger than what is acceptable. Hence,
improvement in the handover latency performance due to security
procedures is a necessary objective.
There is relevant work undertaken by various standards organizations.
But these efforts are scoped to a specific access technology. IEEE
802.11f has defined transfer of Security context from one AP to
another. IEEE 802.11i defines a pre-authentication mechanism for use
in 802.11 variant wireless networks. This mechanism allows mobile
devices to make pre-authentication by establishing link-layer
security associations with one or more target authenticators by
sending 802.1X messages directly to the target authenticators bridged
via the serving authenticator. Presently, IEEE 802.11r WG has been
working to define Fast BSS transition mechanisms involving a
definition of key management hierarchy and mechanisms for link-layer
pre-authentication and setup of session keys before the re-
association to the target AP. These mechanisms, as indicated before,
are defined for IEEE 802.11 technologies and only applicable within a
certain access domain and fall short when it comes to inter-access
technology handovers. They also require L2 (e.g. Ethernet)
connectivity for transfer of encapsulated signaling to the target AP.
As various flavors of wireless technologies are increasingly
available, there is a growing demand for seamless inter-access
technology mobility and handovers. This is particularly beneficial
in the presence of high bandwidth wireless technologies (e.g. IEEE
802.11a/b/g) with only hotspot like coverages while the overlay
licensed wireless/cellular coverages are expensive and relatively
lower bandwidth. There is a strong motivation to allow seamless
Ohba, et al. Expires October 3, 2006 [Page 5]
Internet-Draft Pre-authentication Problem Statement Apr 2006
inter-technology handovers for all kinds of data communications.
Hence, the security optimization mechanisms for better handover
performance must be looked at from the IP level for being common over
different access technologies.
Solutions for mobility security optimizations can be largely seen as
security context transfer, handover keying or pre-authentication.
Security context transfer involves transfer of reusable key context
in the new point of attachment. However, the recent AAA key
management requirement [I-D.housley-aaa-key-mgmt] does not recommend
context transfer of reusable key context because of domino effect in
which a compromise of an authenticator will lead to a compromise of
another authenticator. Nakhjiri et al [I-D.nakhjiri-aaa-hokey-ps]
discusses handover keying. Handover keying uses an existing EAP-
generated key for deriving a key to be used for a target
authenticator in order to reduce the handover delay, which eliminates
the need for running EAP for each inter-authenticator handover. On
the other hand, there are certain cases where an EAP-generated key
does not exist or is not usable for handover keying at the time of
handover and an EAP run is not avoidable to generate a key for the
target authenticator. One case is an inter-domain handover without
any trust relationship between domains. Another case is a handover
to an existing technology that does not support handover keying.
Pre-authentication discussed in this document is based on executing
EAP between a mobile node and a target authenticator via the serving
authenticator prior to handover to the target authenticator, where
the serving and target authenticators are in different subnets or of
different link-layer technologies. Pre-authentication would enable
the mobile device to authenticate and setup keys prior to connecting
to the target authenticator. This framework has general
applicability to various deployment scenarios. Note that pre-
authentication for intra-technology intra-subnet handover should be
solved by each link-layer and thus out of the scope of this document.
Figure 1 shows the functional elements that are related to pre-
authentication.
Ohba, et al. Expires October 3, 2006 [Page 6]
Internet-Draft Pre-authentication Problem Statement Apr 2006
+------+ +-------------+ +-------+
|Mobile|---------| Serving | / \
| Node | |Authenticator|------/ \
+------+ +-------------+ / \
. / \ +----------+
. Move + Internet +----|AAA Server|
. \ / +----------+
v +-------------+ \ /
| Target |------\ /
|Authenticator| \ /
+-------------+ +-------+
Figure 1: Pre-authentication Functional Elements
A mobile node is attached to the serving access network. Before the
mobile node performs handover from the serving access network to a
target access network, it performs pre-authentication with a target
authenticator, an authenticator in the target access network, via the
serving access network. The mobile node may perform pre-
authentication with one or more target authenticators. It is assumed
that each authenticator has an IP address. Authenticators may be on
different IP links. It is assumed that there is at least one target
authenticator in each target access network while the serving access
network may or may not have a serving authenticator. The serving and
target access networks may use different link-layer technologies.
Each authenticator has the functionality of EAP authenticator which
is either standalone EAP authenticator or pass-through EAP
authenticator. When an authenticator acts as a standalone EAP
authenticator, it also has the functionality of EAP server. On the
other hand, when an authenticator acts as a pass-through EAP
authenticator, it communicates with EAP server typically implemented
on a AAA server using a AAA protocol such as RADIUS and Diameter.
If the target authenticator is of an existing link-layer technology
that uses an MSK (Master Session Key) [I-D.ietf-eap-keying] for
generating lower-layer ciphering keys, pre-authentication is used for
proactively generating the MSK for the target authenticator.
Otherwise, if the target authenticator supports handover keying, pre-
authentication is used for proactively generating handover keys for
multiple authenticators including the target authenticator.
Ohba, et al. Expires October 3, 2006 [Page 7]
Internet-Draft Pre-authentication Problem Statement Apr 2006
3. Usage Scenarios
There are two scenarios on how pre-authentication signaling can
happen among a mobile node, a serving authenticator, a target
authenticator and a AAA server, depending on how the serving
authenticator is involved in the pre-authentication signaling.
3.1. Direct Pre-authentication
Direct pre-authentication signaling is shown in Figure 2.
Mobile Serving Target AAA
Node Authenticator Authenticator Server
(MN) (SA) (TA)
| | | |
| | | |
| MN-TA Signaling (L3) | AAA |
|<--------------------+----------------------->|<----------------->|
| | | |
| | | |
Figure 2: Direct Pre-authentication
In this type of pre-authentication, pre-authentication signaling is
transparent to the serving authenticator or there may be no serving
authenticator at all in the serving access network.
Direct pre-authentication is needed when the same authentication
credentials are not used for network access authentication for the
serving and target access networks, e.g., when different AAA servers
are used for the serving and target access networks and no
communication is allowed between the AAA servers.
[I-D.ietf-pana-preauth] is identified as a protocol to realize direct
pre-authentication.
3.2. Indirect Pre-authentication
Indirect pre-authentication signaling is shown in Figure 3.
Ohba, et al. Expires October 3, 2006 [Page 8]
Internet-Draft Pre-authentication Problem Statement Apr 2006
Mobile Serving Target AAA
Node Authenticator Authenticator Server
(MN) (SA) (TA)
| | | |
| | | |
| MN-SA Signaling | SA-TA Signaling | AAA |
| (L2 or L3) | (L3) | |
|<------------------->|<---------------------->|<----------------->|
| | | |
| | | |
Figure 3: Indirect Pre-authentication
With indirect pre-authentication, the serving authenticator is
involved in pre-authentication signaling. Indirect pre-
authentication is needed if IP communication is not allowed between
the target authenticator and unauthorized nodes for security reasons.
Also, indirect pre-authentication allows the serving network to
select an appropriate target authenticator.
Indirect pre-authentication signaling is spliced into mobile node to
serving authenticator signaling (MN-SA signaling) and serving
authenticator to target authenticator signaling (SA-TA signaling).
SA-TA signaling is performed over L3. This is because it is not
reasonable to assume that the serving authenticator and the target
authenticator are on the same IP link.
MN-SA signaling is performed over L2 or L3. L2 signaling is needed
if IP communication is not allowed between the serving authenticator
and any node over the wireless interface of the serving authenticator
even if the node is authorized for communicating with other nodes
over IP. On the other hand, L3 signaling is needed if the serving
authenticator is not on the same IP link as the mobile node.
The role of the serving authenticator in indirect pre-authentication
is to bridge pre-authentication signaling between the mobile node and
the target authenticator and not to act as an EAP authenticator,
while it acts as an EAP authenticator for normal authentication
signaling. This is illustrated in Figure 4.
Ohba, et al. Expires October 3, 2006 [Page 9]
Internet-Draft Pre-authentication Problem Statement Apr 2006
Mobile Serving Target
Node Authenticator Authenticator
(MN) (SA) (TA)
+-----------+ +-----------+
| |<- - - - - - - - - - - - - - - - - - ->| |
| EAP Peer | +-----------------------------+ | EAP Auth- |
| | | Pre-authentication Bridging | | enticator |
+-----------+ +-----------+-----+-----------+ +-----------+
| MN-SA | | MN-SA | | SA-TA | | SA-TA |
| Signaling |<-->| Signaling | | Signaling |<-->| Signaling |
| Layer | | Layer | | Layer | | Layer |
+-----------+ +-----------+ +-----------+ +-----------+
Figure 4: Indirect Pre-authentication Layering Model
Ohba, et al. Expires October 3, 2006 [Page 10]
Internet-Draft Pre-authentication Problem Statement Apr 2006
4. AAA Issues
In pre-authentication, AAA authentication and authorization for a
target authenticator while application sessions are in progress via
the serving network. The goal of pre-authentication is to avoid AAA
signaling when or soon after the device moves.
The AAA server needs to distinguish pre-authentication from normal
authentication. This is needed if users may only be allowed to have
a single authorization session at the same time. While there is a
proprietary solution to distinguish pre-authentication and normal
authentication for a particular link-layer technology (e.g., use of a
null BSSID in Called-Station-Id RADIUS attribute for indicating IEEE
802.11i pre-authentication), a standard solution needs to be
developed to solve this problem as pre-authentication may be
performed across multiple link-layer technologies.
The AAA server also needs to know how long to hold the session before
timing out. Session timeout for pre-authentication may be different
for a normal session. If a pre-authentication session lifetime
expires before the mobile node moves to the target network, the state
for the session should be deleted even if normal session lifetime
remains. Although implementations can implement its own pre-
authentication session lifetime [I-D.ietf-eap-keying], defining a
pre-authentication session lifetime in AAA protocols is more useful
to allow more explicit control on pre-authorized resources.
Ohba, et al. Expires October 3, 2006 [Page 11]
Internet-Draft Pre-authentication Problem Statement Apr 2006
5. Out-of-scope Issues
The following issues are not discussed in the scope of pre-
authentication problem.
o Pre-reserving resources using AAA protocols. Although resource
pre-reservation is an important aspect that is closely related to
pre-authentication and needed for optimizing handover performance,
it is recognized that the topic of resource reservation is best
left to the policies of the AAA entities. That is, regular AAA
transactions will carry all the usual attributes about the
requested session. If the AAA entities wish to, say, decline a
pre-authentication request due to resource depletion or cost, or
charge extra, they can do so.
o Accounting, especially accounting for pre-reserved resources.
There might be nothing special to do with accounting to support
pre-authentication if time-limited resource holding is used.
o Context transfer. From pre-authentication perspective, context
transfer is not useful. This is because pre-authentication needs
AAA signaling with EAP authentication. Resources can be assigned
via this pre-authentication AAA exchange instead of using context
transfer.
Ohba, et al. Expires October 3, 2006 [Page 12]
Internet-Draft Pre-authentication Problem Statement Apr 2006
6. Security Considerations
Since pre-authentication described in this document needs to work
across multiple authenticators, any solution for this problem needs
considerations on the following security threats.
First, a possible resource consumption denial of service attack where
an attacker that is not on the same IP link as the mobile node or the
target authenticator may send unprotected pre-authentication messages
to the mobile node or the target authenticator to let the legitimate
mobile node and target authenticator spend their computational and
bandwidth resources.
Second, consideration for the Channel Binding problem described in
[I-D.ietf-eap-keying] is needed as lack of Channel Binding may cause
a man-in-the-middle attack on payload routing [I-D.ietf-eap-netsel-
problem]. It should be noted that it would be easier to launch a
Channel Binding attack for pre-authentication than normal
authentication because an attacker does not need to be physically on
the same link as the legitimate mobile node in the case of pre-
authentication.
Ohba, et al. Expires October 3, 2006 [Page 13]
Internet-Draft Pre-authentication Problem Statement Apr 2006
7. IANA Considerations
This document has no actions for IANA.
Ohba, et al. Expires October 3, 2006 [Page 14]
Internet-Draft Pre-authentication Problem Statement Apr 2006
8. Acknowledgments
The authors would like to thank Jari Arkko and Madjid Nakhjiri for
their valuable input.
Ohba, et al. Expires October 3, 2006 [Page 15]
Internet-Draft Pre-authentication Problem Statement Apr 2006
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-12 (work in
progress), April 2006.
[I-D.ietf-pana-preauth]
Ohba, Y., "Pre-authentication Support for PANA",
draft-ietf-pana-preauth-01 (work in progress), March 2006.
[I-D.ietf-eap-netsel-problem]
Arkko, J. and B. Aboba, "Network Discovery and Selection
Problem", draft-ietf-eap-netsel-problem-03 (work in
progress), October 2005.
9.2. Informative References
[I-D.ohba-mobopts-heterogeneous-requirement]
Dutta, A., "Problem Statement for Heterogeneous Handover",
draft-ohba-mobopts-heterogeneous-requirement-01 (work in
progress), March 2006.
[I-D.nakhjiri-aaa-hokey-ps]
Nakhjiri, M., "AAA based Keying for Wireless Handovers:
Problem Statement", draft-nakhjiri-aaa-hokey-ps-01 (work
in progress), January 2006.
[I-D.housley-aaa-key-mgmt]
Housley, R. and B. Aboba, "Guidance for AAA Key
Management", draft-housley-aaa-key-mgmt-02 (work in
progress), March 2006.
[ITU] ITU-T, "General Characteristics of International Telephone
Connections and International Telephone Circuits: One-Way
Transmission Time", ITU-T Recommendation G.114 1998.
[ETSI] ETSI, "Telecommunications and Internet Protocol
Harmonization Over Networks (TIPHON) Release 3: End-to-end
Ohba, et al. Expires October 3, 2006 [Page 16]
Internet-Draft Pre-authentication Problem Statement Apr 2006
Quality of Service in TIPHON systems; Part 1: General
aspects of Quality of Service.", ETSI TR 101 329-6 V2.1.1.
[georgiades]
Georgiades, M., "Context transfer support for IP-based
mobility management", CCSR Awards for Research Excellence
2004.
Ohba, et al. Expires October 3, 2006 [Page 17]
Internet-Draft Pre-authentication Problem Statement Apr 2006
Appendix A. Performance Requirements
In order to provide the desirable quality of service for interactive
VoIP and streaming traffic during handoff, one needs to limit the
value of end-to-end delay, jitter and packet loss to a certain
threshold level. ITU-T and ITU-R standards define the acceptable
values for these parameters. For example for one-way delay, ITU-T
G.114 [ITU] recommends 150 ms as the upper limit for most of the
applications, and 400 ms as generally unacceptable delay. One way
delay tolerance for video conferencing is in the range of 200 to 300
ms. Also if an out-of-order packet is received after a certain
threshold, it is considered lost. The performance requirement will
vary based on the type of application and its characteristics such as
delay tolerance and loss tolerance limit. Interactive traffic such
as VoIP and streaming traffic will have different tolerance for delay
and packet loss. For example, according to ETSI TR 101 [ETSI] a
normal voice conversation can tolerate up to 2% packet loss.
Similarly there are other factors such as Transmission Rating Factor
(R) standardized within ITU-T G.107, End to End delay (one way mouth-
to-ear) and call blocking ratio that determine the QoS metrics. An R
value of 50 is considered to be poor and a value of 90 can be
considered as the best that provides most user satisfaction. As an
example, a class B QoS which is equivalent to cellular telephony has
a R factor that is greater than 70, E2E delay of less than 150 ms and
call blocking ratio which is less than or equal to 0.15. Class A QoS
that is the highest and is equivalent to fixed phone quality has an R
value that is more than 80 and an end-to-end delay that is less than
100 ms. Similarly, 3GPP TS23.107 defines 4 application classes:
conversational, streaming, interactive and background each with
different set of end-to-end delay and QoS requirement. The streaming
class has the tolerable packet (SDU) error rates ranging from 0.1 to
0.00001 and the transfer delay of less than 300ms. In short, the
delay and packet loss tolerance value will depend upon the type of
application and different standard bodies and vendors provide
different specification for each type of application and thus any
optimized handoff mechanism will need to take these values into
consideration.
It is desirable to support a heterogeneous handover that is agnostic
to link-layer technologies in an optimized and secure fashion without
incurring unreasonable complexity while providing seamless handover
experience to the user. As a mobile goes through a handover process,
it is subjected to handover delay because of the rebinding of
properties at several layers of the protocol stack, such as layer 2,
layer 3 and application layer. There are several common properties
that contribute to the re-establishment or modification of these
layers during handover. These properties can mostly be attributed to
things such as access characteristics (e.g., bandwidth, channel
Ohba, et al. Expires October 3, 2006 [Page 18]
Internet-Draft Pre-authentication Problem Statement Apr 2006
characteristics, channel scan, access point association), access
mechanism (e.g. CDMA, CSMA/CA, TDMA), configuration of layer 3
parameters such as IP address acquisition, re-authentication, re-
authorization, rebinding of security association at all layers,
binding update etc. Although each of the components during the
handover process that contributes to the handover delay needs to be
optimized, we focus our discussion on optimizing the delay due to
authentication and authorization.
Ohba, et al. Expires October 3, 2006 [Page 19]
Internet-Draft Pre-authentication Problem Statement Apr 2006
Authors' Addresses
Yoshihiro Ohba
Toshiba America Research, Inc.
1 Telcordia Drive
Piscataway, NJ 08854
USA
Phone: +1 732 699 5365
Email: yohba@tari.toshiba.com
Ashutosh Dutta
Telcordia
1 Telcordia Drive
Piscataway, NJ 08854
USA
Phone: +1 732 699 3130
Email: adutta@research.telcordia.com
Srivinas Sreemanthula
Nokia Research Center
6000 Connection Dr.
Irving, TX 75028
USA
Email: srinivas.sreemanthula@nokia.com
Ohba, et al. Expires October 3, 2006 [Page 20]
Internet-Draft Pre-authentication Problem Statement Apr 2006
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 (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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Ohba, et al. Expires October 3, 2006 [Page 21]
