One document matched: draft-dondeti-eap-vkh-00.txt
Network Working Group L. Dondeti
Internet-Draft V. Narayanan
Intended status: Standards Track QUALCOMM, Inc.
Expires: April 19, 2007 October 16, 2006
EAP Keying and Re-authentication in Visited Domains
draft-dondeti-eap-vkh-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 April 19, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document specifies a visited domain key hierarchy derived from
the extended master session key (EMSK) from EAP to facilitate visited
domain key management for various purposes including fast handovers
and visited domain services. The visited domain key hierarchy avoids
the latency associated with communicating with the home domain as in
case of a full EAP method run or even in a single round trip as with
the EAP efficient reauthentication scheme, and that is especially
desirable when the protocol is in the critical path of a handover.
Dondeti & Narayanan Expires April 19, 2007 [Page 1]
Internet-Draft EAP VKH October 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Visited Domain Keying . . . . . . . . . . . . . . 4
4. EMSK Hierarchy for Visited Domains . . . . . . . . . . . . . . 4
4.1. VRK Derivation and Properties . . . . . . . . . . . . . . 5
4.2. VMSK Derivation and Properties . . . . . . . . . . . . . . 6
4.2.1. VMSK Establishment and Delivery . . . . . . . . . . . 8
5. Intra-Visited Domain Re-authentication Keying Hierarchy . . . 11
5.1. V-rRK Derivation and Properties . . . . . . . . . . . . . 11
5.2. V-rRK Usage and Derived Keys . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Dondeti & Narayanan Expires April 19, 2007 [Page 2]
Internet-Draft EAP VKH October 2006
1. Introduction
The extensible authentication protocol (EAP) specified in [1]
requires the peer to authenticate to an EAP server located typically
in the peer's home domain. The authentication process may involve
several roundtrips in case of a full EAP authentication, or a single
roundtrip in case of the EAP efficient reauthentication (EAP-ER) [2]
protocol. When the EAP peer is roaming in a visited domain, even a
single roundtrip to the home domain is often unacceptable, especially
when the EAP authentication needs to take place in the critical path
of a handover.
To avoid the need to revisit the home network each time an EAP peer
moves to a new EAP authenticator within a visited domain, a visited
domain keying hierarchy (V-KH) for re-authentication is specified in
this document. Corresponding to this hierarchy, the EAP-ER protocol
operation to support fast handovers with the availability of the V-KH
is also specified.
2. Terminology
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 [3].
This document uses terminology defined in [1]. In addition, this
document uses the following terms:
Visited Domain
A domain that an EAP peer may attach to while roaming. This
domain is different from the domain that hosts the EAP server with
which the peer shares credentials.
Visited Root Key (VRK)
This is the Usage Specific Root Key derived from the EMSK for
visited domain keying purposes. Specific visited domain session
keys for various visited domains are derived from the VRK.
Visited Domain Master Session Key (VMSK)
The VMSK is derived from the VRK for a given visited domain to
serve as the master key for services within that visited domain.
This document only defines EAP efficient re-authentication service
within the visited domain.
Dondeti & Narayanan Expires April 19, 2007 [Page 3]
Internet-Draft EAP VKH October 2006
3. Overview of Visited Domain Keying
The idea behind visited domain keying is that an EAP peer, after
completion of at least one full EAP exchange with its home domain EAP
server, can re-authenticate within the visited network by running an
EAP-ER exchange with a visited domain EAP-ER server. This process
does require the visited domain to host an EAP-ER server that
supports the V-KH and EAP-ER - however, it does not require that the
visited domain server support any EAP methods. Given that EAP-ER is
method agnostic, it works well with the visited domain support
concept. The EAP peer still only has to support methods that its
home domain EAP server supports. As long as the peer supports the
V-KH and EAP-ER, it will be able to perform EAP-ER within a visited
domain that supports EAP-ER.
Either during a full EAP exchange or during an EAP-ER bootstrap
exchange as specified in [2], a visited domain EAP-ER server may
request keying material for the peer from the home domain EAP server
performing the EAP authentication with the peer. The visited domain
key request message is sent in a AAA attribute to the AAA server,
which is then relayed to the EAP layer. The home EAP server will
derive a VMSK (Visited domain Master Session Key) specific to the
requesting domain and provide it in a AAA attribute back to the
requesting visited domain EAP-ER server. In order to preserve the
stateless nature of the visited domain servers, it would be feasible
to provide this key, along with other parameters such as lifetimes
and authorization information to the peer in the form of a ticket
that can later be presented to the visited domain EAP-ER server.
This mechanism will be specified in a later version of this document.
Along with the VMSK, the server MUST send a lifetime and may send
authorization and other policy information pertinent to the peer.
The standardization of any AAA attributes needed to accomplish this
exchange is outside the scope of this document itself and will be
done separately.
4. EMSK Hierarchy for Visited Domains
Dondeti & Narayanan Expires April 19, 2007 [Page 4]
Internet-Draft EAP VKH October 2006
EMSK
|
+------------+-------------+
| | |
rRK VRK ... USRKn
|
+---------+---------+
| |
VMSK1 ... VMSKn
* VMSKx is the root key for the key hierarchy of a given visited domain X
Figure 1: VMSK derivation from the EMSK
The above figure shows the EMSK keying hierarchy as defined in [4].
The re-authentication Root Key (rRK) shown is defined in [2] for the
purpose of EAP re-authentication with the home domain. In many
cases, this may be the same server with which the peer executed a
full EAP exchange. This document defines another USRK called Visited
domain Root Key (VRK). The VRK is then used to derive a specific
VMSK, which is given to an EAP-ER server in a particular visited
domain.
4.1. VRK Derivation and Properties
The VRK is derived from the EMSK using the prf+ operation defined in
RFC4306 [5] as follows.
VRK = prf+ (K, S), where,
K = EMSK and
S = VRK Label
The VRK Label is an IANA-assigned ASCII string "EAP Visited domain
Root Key" assigned from the USRK Key Label name space in accordance
with [4]. This document specifies IANA registration for the VRK
label above.
The PRF used may be specified in the EAP Re-authentication message,
as described in [2]. When that is not available, the default PRF to
be used is HMAC-SHA-256.
Along with the VRK, a unique VRK name is derived to identify the VRK.
The VRK name is derived as follows.
Dondeti & Narayanan Expires April 19, 2007 [Page 5]
Internet-Draft EAP VKH October 2006
VRK_name = NDF-64( EAP Session-ID, VRK Label )
where NDF-64 is the first 64 bits from the output of the name
derivation function (NDF). The NDF is a hash function, currently
specified as SHA-256. The EAP Session-ID MUST be of the EAP session
corresponding to the EMSK used in the derivation of the VRK.
The VRK has the following properties.
o The length of the VRK MUST at least be 64 bytes.
o The VRK is to be used only as a root key for the derivation of
specific VMSKs corresponding to different visited domains and MUST
NOT be used to directly protect any data.
o The VRK is only used for derivation of VMSKs as specified in this
document.
o The VRK must remain on the peer and the server and MUST NOT be
transported to any other entity.
o The VRK is cryptographically separate from any other USRK derived
from the EMSK.
o The lifetime of the VRK is the same as that of the EMSK. The VRK
is expired when the EMSK expires and removed from use at that
time.
o If a new EMSK is derived due to a full EAP exchange, a new VRK
from that EMSK must be derived for the purpose of subsequent VMSK
derivations. The new VRK MUST replace an existing VRK derived
from a previous EMSK.
4.2. VMSK Derivation and Properties
The VMSK is derived from the VRK using the prf+ operation defined in
RFC4306 [5] as follows.
VMSK = prf+ (K, S), where,
K = VRK and
S = Server ID || Domain Name
The server ID is the identity of the server requesting the VMSK.
This should be included as a AAA attribute along with the AAA message
carrying the EAP message requesting the VMSK. The server ID may
typically be the FQDN of the server. In the event that state would
Dondeti & Narayanan Expires April 19, 2007 [Page 6]
Internet-Draft EAP VKH October 2006
be replicated on more than one visited domain server, the server ID
could be a wildcard. The domain name is the realm of the visited
domain requesting the VMSK. When the server ID is an FQDN, the realm
would already be part of that and having a separate domain name is
redundant. However, when other types of server IDs are allowed, it
is important to have the domain name specified separately. For sake
of consistency, the domain name is always specified as above,
irrespective of the nature of the server ID.
The PRF used may be specified in the EAP Re-authentication message,
as described in [2]. When that is not available, the default PRF to
be used is HMAC-SHA-256.
Along with the VMSK, a unique VMSK name is derived to identify the
VMSK.
The VMSK name is derived as follows.
VMSK_name = NDF-64( EAP Session-ID, Server ID || Domain Name )
where NDF-64 is the first 64 bits from the output of the name
derivation function (NDF). The NDF is a hash function, currently
specified as SHA-256. The EAP Session-ID is the session-id of the
full EAP exchange used to derive the corresponding EMSK used as the
parent key.
The VMSK has the following properties.
o The length of the VMSK MUST at least be 64 bytes.
o The VMSK is to be used only as a root key for the derivation of
specific keys for visited domain services such as re-
authentication within the visited domain and MUST NOT be used to
directly protect any data.
o The VMSK is used for derivation of the V-rRKs as specified in this
document. The VMSK may be used for derivation of other visited
domain keys - it is outside the scope of this document to specify
such keys.
o The VMSK MUST NOT be transported to any entity other than the one
requesting it. The VMSK scope must be clearly defined. The VMSK
MUST NOT be used for any purpose other than what is authorized by
the server deriving and distributing the key.
o A given VMSK is cryptographically separate from any other VMSK
derived from the VRK.
Dondeti & Narayanan Expires April 19, 2007 [Page 7]
Internet-Draft EAP VKH October 2006
o The lifetime of the VMSK MUST NOT be greater than the lifetime of
the VRK. The associated lifetime of the VMSK must be transported
along with the VMSK to the entity requesting it. By default, the
lifetime of the VMSK is the same as that of the VRK and the EMSK.
The VMSK MUST be removed from use when the lifetime expires.
o The VMSK and the keys derived from it have limited applicability
and have a specific lifetime. These keys are used to derive other
keys to provide proof of having participated in an EAP
conversation or having received the keys from an entity that
participated in the EAP conversation. No other uses are allowed
as per this specification. Such key scoping is important to
disallow misuse of the keys which might result in compromise of
security sessions established using those keys.
o If a new VRK is derived due to a full EAP exchange, a new VMSK
from that EMSK SHOULD be derived to replace a VMSK that is in use
from the previous EAP exchange.
4.2.1. VMSK Establishment and Delivery
A given VMSK is derived by the home EAP server upon request from a
visited domain. This section specifies the establishment and
transport of the VMSK and associated parameters.
A visited domain AAA server may request a VMSK in the EAP Response
Identity sent by the peer. Alternately, it may request for a VMSK in
the EAP Re-auth Initiate message sent by the peer, in accordance with
[2]. If there is an EAP Re-auth Initiate message from the peer, a
visited domain server that supports VMSKs MUST include a request for
VMSK in the EAP Re-auth Initiate message, even if it had already
included the request in the EAP Response Identity message
corresponding to that peer earlier. This is so that the home server
can send the corresponding parameters to the peer in the EAP Re-auth
Finish message. Further, note that the visited domain entities will
typically be unaware if a VMSK has already been obtained for that
particular peer earlier, as the peer ID may not be available to the
visited domain entities during the EAP exchange.
The home EAP server, upon receiving a request for VMSK, based on
authorization information for the peer, SHOULD provide a VMSK to the
requesting server. The VMSK may be provided along with the EAP
Success message or with the EAP Re-auth Finish message. Along with
the VMSK, the server MAY also provide relevant authorization policy.
When provided with the EAP Re-authentication Finish, the server MUST
also provide the relevant server IDs and visited domain information
for the peer. Specifically, the server MUST provide the visited
domain name to the peer. It MAY provide one or more server IDs to
Dondeti & Narayanan Expires April 19, 2007 [Page 8]
Internet-Draft EAP VKH October 2006
the peer - for e.g., its own server ID and the requesting visited
domain server ID. When the VMSK is provided to the requesting entity
along with the EAP Success message, it is assumed that the peer
obtains the information relevant for computing the VMSK via the lower
layer. Such mechanisms are out of scope of this document.
Based on the information in the EAP Re-auth Finish message, the peer
would be able to derive the VMSK and associated keys for re-
authentication in the visited domain. Upon handoff to an EAP
authenticator within the same domain, the peer SHOULD use the V-rIK
to send an EAP Re-authentication Initiate message to the visited
domain EAP-ER server in accordance with [2].
4.2.1.1. Peer Considerations
The EAP peer, while attached to an authenticator in the visited
domain, may or may not be aware of the domain it is attached to. If
the peer is aware, for instance, via lower layer advertisements, of
the domain it is attached to, it may be aware that the visited domain
supports VMSKs or not. Further, it may also receive the visited
domain EAP-ER server ID via the lower layer or it may be aware via
configuration that the server ID can be a wildcard. In such cases,
the peer may never need to send an EAP Re-auth Initiate message with
the Bootstrap flag set for the purpose of receiving VMSK related
parameters. It may still send an EAP Re-auth Initiate message with
the Bootstrap flag to retrieve some parameters for the home domain,
in accordance with [2].
A peer that supports EAP-ER, in accordance with [2], MAY send an EAP
Re-auth Initiate message with the Bootstrap flag set, immediately
following a full EAP exchange. In response to this, if it receives
an EAP Re-auth Finish message from the server, it MUST process it in
accordance with [2]. In addition, it MUST check if the message
contained a visited domain server ID and a visited domain name. If
it does, the peer MUST compute the VMSK using that information. If
the message contained a visited domain name, but no visited server
ID, the peer MUST use a wildcard entry as the server ID. If the
message contained a temporary peer ID to use within the visited
domain, the peer MUST use that in a subsequent EAP re-auth initiate
message sent within that visited domain. If not, the peer SHOULD use
the V-rIKName as its ID in the visited domain. The V-rIKName
appended with the visited domain name will provide the NAI to use as
the peer ID in the EAP Re-auth Initiate message.
Once a VMSK and subsequent keys for visited domain EAP re-
authentication are available, the peer MUST process EAP Re-
authentication messages in accordance with [2], even though it may be
executed with the visited domain.
Dondeti & Narayanan Expires April 19, 2007 [Page 9]
Internet-Draft EAP VKH October 2006
4.2.1.2. Authenticator Considerations
An authenticator that is compliant with [2] may advertise the
presence of a visited domain EAP-ER server in the lower layer to the
peer. The authenticator has no special considerations for VMSK
support and is transparent to whether the EAP-ER exchange occurs with
the visited domain or the home domain for a given peer.
4.2.1.3. Visited Domain EAP-ER Server Considerations
The visited domain server MAY request a VMSK in an EAP Response
Identity message sent by a peer through an authenticator in the
visited domain. Alternately, it MAY request a VMSK in the EAP Re-
auth Initiate message from the peer. If the request for VMSK was
sent in the EAP Response Identity message, the server MUST retrieve
the VMSK from the AAA message carrying the EAP Success message. If
the result is an EAP failure, no state for that peer must be
established in the visited domain. If the request for VMSK was sent
in the EAP Re-auth Initiate message, the visited domain server MUST
retrieve the VMSK in the AAA message carrying the EAP Re-auth Finish
message.
If the visited EAP-ER server obtains a VMSK, it MUST derive a V-rRK
and a V-rIK from it. It may then serve as the EAP-ER server for
subsequent EAP Re-authentication messages from the peer.
The AAA attributes needed for the VMSK request and delivery are not
defined in this document. These will be specified in a separate
document.
4.2.1.4. Home EAP Server Considerations
Upon receiving a request for a VMSK from the visited EAP-ER server,
the home EAP server SHOULD check if the message contains the server
ID and the domain name of the visited server. If so, the home EAP
server SHOULD derive a VMSK and provide it to the requesting visited
EAP-ER server. If the request was sent along with an EAP Response
Identity message, the key MUST be provided in the EAP Success
message. If the request was sent along with an EAP Re-auth Initiate
message, the key MUST be provided in the EAP Re-auth Finish message.
After transporting the VMSK, the home EAP server MUST delete the VMSK
immediately. The VMSK MUST be securely transported from the home EAP
server to the requesting visited EAP-ER server. If the visited
server ID is unavailable or if the visited EAP-ER server is not
specifically indicated, the server ID in the VMSK Label could be
considered a wildcard. In this case, the message with the VMSK will
be routed via normal AAA routing and it is assumed that there is
Dondeti & Narayanan Expires April 19, 2007 [Page 10]
Internet-Draft EAP VKH October 2006
backend duplication of keying material in the visited domain. The
visited domain name and the appropriate server ID MUST be provided to
the peer in an EAP Re-auth Finish message, if the server received an
EAP Re-auth Initiate message that triggered the derivation of a VMSK.
5. Intra-Visited Domain Re-authentication Keying Hierarchy
VMSK
|
V-rRK
|
+----------+---------------+
| | |
V-rIK V-rMSK1 ... V-rMSKn
Figure 2: Visited Domain Key Hierarchy
The above figure shows a V-KH for re-authentication purposes. A
Visited domain Master Session Key (VMSK) is at the top of the
hierarchy. A visited domain re-authentication root key (V-rRK) is
derived from the VMSK. The V-rRK hierarchy is identical to the rRK
hierarchy for EAP-ER with the home domain; the exception here is that
the scope of these keys is the visited domain that owns the VMSK.
Other keys may be derived from the VMSK - however, such keys are out
of scope of this document.
5.1. V-rRK Derivation and Properties
This document defines the derivation of a Visited domain re-
authentication Root Key (V-rRK) from the VMSK. This key is identical
in purpose to the rRK defined in [2].
The V-rRK is derived from the VMSK using the prf+ operation defined
in RFC4306 [5] as follows.
rRK = prf+ (K, S), where,
K = VMSK and
S = rRK Label
The rRK Label is an IANA-assigned ASCII string "EAP Re-authentication
Root Key" as specified in [2].
The PRF used is specified in the EAP Re-authentication Response. The
Dondeti & Narayanan Expires April 19, 2007 [Page 11]
Internet-Draft EAP VKH October 2006
default PRF used is HMAC-SHA-256.
The V-rRK has the following properties.
o The V-rRK MUST be 64 octets in length.
o The V-rRK is to be used only as a root key for re-authentication
within the visited domain and never used to directly protect any
data.
o The V-rRK is only used for derivation of V-rIK and V-rMSK as
specified in this document.
o The rRK must remain on the peer and the server deriving it and
MUST NOT be transported to any other entity.
o The V-rRK is cryptographically separate from any other key derived
from the VMSK.
o The lifetime of the V-rRK is the same as that of the VMSK. The
V-rRK is expired when the VMSK expires and removed from use at
that time.
o If a new VMSK is available for the visited domain, a new V-rRK
from that VMSK must be derived for the purpose of subsequent
EAP-ER exchanges in the visited domain. The new V-rRK MUST
replace an existing V-rRK derived from a previous VMSK.
5.2. V-rRK Usage and Derived Keys
The V-rRK is used within the visited domain in exactly the same
manner as the rRK defined in [2]. The scope of all the derived keys,
however, is limited to the visited domain to which the server
belongs.
6. Security Considerations
All the security considerations stated in [2] are also applicable for
this document. In addition, scope of the VMSK MUST be restricted to
the visited domain to which the VMSK is provided. Further, when a
non-wildcard visited domain server ID is used to compute the VMSK the
scope of the VMSK MUST be limited to the particular visited EAP-ER
server to which the key is provided. The VMSK MUST remain on the
peer and the visited domain EAP-ER server and MUST NOT be transported
to any other entity, including other visited domain EAP-ER servers.
The keys defined by this document must adhere to the properties and
Dondeti & Narayanan Expires April 19, 2007 [Page 12]
Internet-Draft EAP VKH October 2006
requirements stated here: A VMSK MUST NOT be used after expiry of its
lifetime. When a new VMSK is available, the old VMSK MUST be
replaced by the new one and the old key MUST NOT be used to compute
any subsequent child keys.
The VMSK MUST be securely transported from the EAP server to the
visited domain entity requesting it. The visited domain entity MUST
be authorized to receive such a key and perform re-authentication for
the EAP peer. Authorization may be based on policies and such a
process itself is outside the scope of this document.
7. IANA Considerations
TBD
8. Acknowledgments
We would like to thank, in alphabetical order, Bernard Aboba, Parag
Agashe, Paul Bender, Sam Hartman, Russ Housley, Joe Salowey, George
Tsirtsis, Fatih Ulupinar, Michaela Vanderveen, and Jun Wang for
several useful discussions and reviews of the contents of this
document.
9. References
9.1. Normative References
[1] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748,
June 2004.
[2] Narayanan, V. and L. Dondeti, "EAP Extensions for Efficient Re-
authentication", draft-vidya-eap-er-00 (work in progress),
June 2006.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Salowey, J., "Specification for the Derivation of Usage Specific
Root Keys (USRK) from an Extended Master Session Key (EMSK)",
draft-salowey-eap-emsk-deriv-01 (work in progress), June 2006.
[5] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
December 2005.
Dondeti & Narayanan Expires April 19, 2007 [Page 13]
Internet-Draft EAP VKH October 2006
[6] Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-14 (work in
progress), June 2006.
9.2. Informative References
[7] Housley, R. and B. Aboba, "Guidance for AAA Key Management",
draft-housley-aaa-key-mgmt-04 (work in progress), October 2006.
[8] Narayanan, V. and L. Dondeti, "Gap analysis on the EAP keying
hierarchy", draft-vidya-eap-keying-gap-analysis-00 (work in
progress), April 2006.
[9] Dondeti, L. and V. Narayanan, "EAP Extensions Problem
Statement", draft-dondeti-eapext-ps-00 (work in progress),
June 2006.
Authors' Addresses
Lakshminath Dondeti
QUALCOMM, Inc.
5775 Morehouse Dr
San Diego, CA
USA
Phone: +1 858-845-1267
Email: ldondeti@qualcomm.com
Vidya Narayanan
QUALCOMM, Inc.
5775 Morehouse Dr
San Diego, CA
USA
Phone: +1 858-845-2483
Email: vidyan@qualcomm.com
Dondeti & Narayanan Expires April 19, 2007 [Page 14]
Internet-Draft EAP VKH October 2006
Full 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.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Dondeti & Narayanan Expires April 19, 2007 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-23 02:59:00 |