One document matched: draft-giaretta-mip6-amsk-01.txt
Differences from draft-giaretta-mip6-amsk-00.txt
MIP6 Working Group G. Giaretta
Internet Draft I. Guardini
Expires: September 2006 E. Demaria
M. La Monaca
Telecom Italia
J. Bournelle
M. Laurent-Maknavicius
GET/INT
March 2006
Application Master Session Key (AMSK) for Mobile IPv6
<draft-giaretta-mip6-amsk-01.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.
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Abstract
The Extensible Authentication Protocol (EAP) defines an extensible
framework for performing network access authentication. Most EAP
authentication algorithms, also known as "methods", export keying
material that can be used with lower layer ciphersuites. It has been
proposed [11] to leverage the EAP keying framework to derive
Application Master Session Keys (AMSKs) for specific applications or
services.
Giaretta, et al. Expires - April 2006 [Page 1]
Internet-Draft AMSK for Mobile IPv6 March 2006
This document defines how to generate Application Master Session Keys
(AMSKs) specific to Mobile IPv6. These AMSKs can be used by Mobile
Node and Home Agent to bootstrap Mobile IPv6 protocol operation.
Table of Contents
1. Introduction................................................3
2. Terminology.................................................4
3. Applicability Statement.....................................6
3.1 Bootstrapping IPsec SAs with Pre-shared keys.............6
3.2 Bootstrapping rfc4285-based SAs..........................7
4. AMSK derivation.............................................9
5. Open issues................................................11
5.1 Key hierarchy...........................................11
5.2 Key length (and other key related parameters)...........11
5.3 rfc4285 SAs.............................................12
5.4 Key Freshness...........................................12
5.5 Multiple EAP sessions...................................12
5.6 Identity management and key binding.....................12
6. AAA-HA interface requirements..............................13
7. Security Considerations....................................14
8. IANA Considerations........................................15
9. Acknowledgments............................................16
10. References.................................................16
10.1 Normative References..................................16
10.2 Informative References................................17
Authors' Addresses..............................................18
Intellectual Property Statement.................................19
Giaretta, et al. Expires - September 2006 [Page 2]
Internet-Draft AMSK for Mobile IPv6 March 2006
1. Introduction
Mobile IPv6 (MIPv6) requires that Mobile Nodes (MNs) and Home Agents
(HAs) share a security association to protect binding management
signaling. The MIPv6 protocol specification [1] mandates the use of
IPsec for this purpose and therefore requires the MN to be
provisioned with the data needed to bootstrap an IPsec Security
Association (SA) with its Home Agent. This is one of the main issues
of the so called Mobile IPv6 bootstrapping problem [10]. The IPsec SA
between MN and HA can be established from a shared secret using IKE
with Pre-Shared Key (PSK) authentication [6]. Alternatively, the
Authentication Protocol for MIPv6 [5] presents a different security
mechanism for Mobile IPv6 that requires a shared secret between MN
and HA to authenticate the binding messages. In scenarios where
network access control is based on EAP those shared secrets can be
derived from the EAP key hierarchy [12].
This document defines how to generate Application Master Session Keys
(AMSKs) specific for Mobile IPv6 bootstrapping, both for IPsec SAs
and Authentication Protocol SAs. The solution presented in this
document is agnostic of the AAA-HA interface model (e.g. push/pull
model).
Giaretta, et al. Expires - September 2006 [Page 3]
Internet-Draft AMSK for Mobile IPv6 March 2006
2. Terminology
Most of the terms used in this document are defined in this section;
more detailed general mobility and EAP terminology can be found in
[7] and [12].
MSA
Mobility Service Authorizer. A service provider that authorizes
Mobile IPv6 service.
ASA
Access Service Authorizer. A network operator that
authenticates a mobile host and establishes the mobile host's
authorization to receive Internet service.
Split scenario
A scenario where the mobility service and the network access
service are authorized by different entities (MSA!=ASA).
Integrated scenario
A scenario where the mobility service and the network access
service are authorized by the same entity (MSA=ASA).
EAP server
The entity that terminates the EAP authentication method with
the peer. In the case where no backend authentication server
is used, the EAP server is part of the authenticator. In the
case where the authenticator operates in pass-through mode, the
EAP server is located on the backend authentication server.
MSK Master Session key
Keying material that is derived between the EAP peer and server
and exported by the EAP method. The MSK is at least 64 octets
in length.
EMSK Extended Master Session Key
Additional keying material derived between the peer and server
that is exported by the EAP method. The EMSK is at least 64
octets in length, and is never shared with a third party.
Giaretta, et al. Expires - September 2006 [Page 4]
Internet-Draft AMSK for Mobile IPv6 March 2006
AMSK Application Master Session Key
Keys derived from the EMSK which are cryptographically separate
from each other.
MN Mobile Node
A node that can change its point of attachment from one link to
another, while still being reachable via its home address.
HA Home Agent
A router on a mobile node's home link with which the mobile
node has registered its current care-of address. While the
mobile node is away from home, the home agent intercepts
packets on the home link addressed to the mobile node's home
address, encapsulates them, and tunnels them to the mobile
node's registered care-of address.
BU Binding Update
A message indicating a mobile node's current mobility binding,
and in particular its care-of address.
BA Binding Acknowledgement
A message used to acknowledge receipt of a Binding Update.
Giaretta, et al. Expires - September 2006 [Page 5]
Internet-Draft AMSK for Mobile IPv6 March 2006
3. Applicability Statement
The Mobile IPv6 bootstrapping problem statement [10] describes two
main scenarios. In the first scenario (i.e. the split scenario), the
mobility service is authorized by a different service authorizer
(MSA, Mobility Service Authorizer) than the basic network access
authorizer (ASA, Access Service Authorizer). In the second scenario
(i.e. the integrated scenario), the mobile node's mobility service is
authorized by the same service authorizer as the basic network access
service authorizer. This implies that only in the integrated
scenario it is possible to leverage the network access authentication
to bootstrap mobility service. Therefore, the approach defined in
this document applies only to the integrated scenario.
This specification assumes that AAA server and the EAP server are co-
located, with the latter exporting the keys to the former. As already
pointed out, the solution presented here addresses both the IPsec and
rfc4285-based SAs bootstrapping.
3.1 Bootstrapping IPsec SAs with Pre-shared keys
The bootstrapping solution defined for integrated scenario [18]
requires the mobile node to run an EAP exchange over IKEv2. In case
the mobile node uses EAP for network access authentication, this
implies that the MN executes two EAP exchanges, possibly with the
same EAP server and using the same credentials.
Therefore, in this scenario an AMSK, named IKEv2-AMSK, can be used as
the IKEv2 Pre-shared Key (PSK), with the advantage that only one EAP
exchange is performed (during network access authentication).
The key is derived by the MN and the AAAH server and needs to be
transferred to the HA (together with the MN/key identifier). Two
different approaches are possible:
1. The AAAH server sends proactively the key to the HA (push
approach). A requirement for this approach is that the AAAH
server needs to know the HA assigned to the MN.
2. The HA requests to the AAAH the PSK during the IKEv2 exchange
with the MN (pull approach). In this case the HA needs to know
the AAAH server used by a specific MN for network access
authentication.
Figure 1 and 2 (pag. 8) show the message flow of the two models. Note
that in both approaches the MN/key identifier must be sent via the
AAA-HA interface and needs to be the same identifier used in IKEv2.
Giaretta, et al. Expires - September 2006 [Page 6]
Internet-Draft AMSK for Mobile IPv6 March 2006
3.2 Bootstrapping rfc4285-based SAs
Concerning rfc4285-based SAs, the keying material derived from EAP
can be exploited in two different ways, since two possible
authentication options are specified:
1. MN-HA Mobility Message Authentication Option. In this case, an
AMSK, named MN-HA-AMSK, is used as the shared key for the
security association between the MN and HA. Similarly to the
IKEv2 Pre-shared key case, both the push and pull model can be
envisioned for key delivery. The MN/key identifier must be sent
via the AAA-HA interface and needs to be the same identifier to
be used as Mobile Node Identifier (in the form of NAI) in the
BUs.
2. MN-AAA Mobility Message Authentication Option. In this case, an
AMSK, named MN-AAA-AMSK, is used as the shared-key for the
security association between the MN and the AAAH server. In
this case, no key delivery is needed.
Giaretta, et al. Expires - September 2006 [Page 7]
Internet-Draft AMSK for Mobile IPv6 March 2006
EAP PEER EAP-AUTH EAP-AUTH Server Home
MN NAS Server Agent
| | |
| EAP session | |
|<----------------------------->| |
| | |
| o o o | |
| | |
| | Access-Accept | |
A| | EAP Success, MSK | |
M| EAP Succ. |<------------------+ |
S|<----------| \ ------------ |
K| | AMSKs | |
s| |genereration| |
| ------------ |
| |
| Binging Update / IKEv2 IKE_AUTH |
|-------------------------------------------------------------->|
| |
| | "Key-Request, MN identity" |
| |<------------------------------|
| | "Keying material" |
| | ----------------------------->|
Figure 1 - Pull model message flow
EAP PEER EAP-AUTH EAP-AUTH Server Home
MN NAS Server Agent
| | |
| EAP session | |
|<----------------------------->| |
| | |
| o o o | |
| | |
| | Access-Accept | |
A| | EAP Success, MSK | "Keying material, MN identity"|
M| EAP Succ. |<------------------+------------------------------>|
S|<----------| \ ------------ |
K| | AMSKs | |
s| |genereration| |
| ------------ |
| |
| Binging Update / IKEv2 IKE AUTH |
|-------------------------------------------------------------->|
Figure 2 - Push model message flow
Giaretta, et al. Expires - September 2006 [Page 8]
Internet-Draft AMSK for Mobile IPv6 March 2006
4. AMSK derivation
The key hierarchy proposed in this document is depicted in Figure 3.
Three different AMSKs are defined: MN-AAA AMSK, MN-HA AMSK and IKEv2-
AMSK. The basic assumption is that the EMSK is exported by the EAP
server to the AAA server; these keys are then derived directly from
the EMSK by the AAA server of the MSA.
EMSK
|
+----------------------------------+
| | |
MN-AAA AMSK MN-HA AMSK IKEv2-AMSK
Figure 3 - Proposed key hierarchy
Mobile IPv6 AMSKs are derived through the general key derivation
function (KDF) specified in [12]. The KDF is shown below for the sake
of clarity.
KDF (K,L,D,O) = T1 | T2 | T3 | T4 | ...
where:
T1 = prf (K, S | 0x01)
T2 = prf (K, T1 | S | 0x02)
T3 = prf (K, T2 | S | 0x03)
T4 = prf (K, T3 | S | 0x04)
prf = HMAC-SHA1
K = EMSK
L = key label
D = application data
O = output length
S = L | " " | D | O
The application specific parameters are set as follows:
IKEv2 Pre-shared key AMSK (IKEv2-AMSK):
key label = "MIPv6-IKEv2-key"
application data = "HA Address"
output length = variable (default 128)
(key name: IKEv2-AMSK | EAP Session-ID)
rfc4285 MN-HA key (MN-HA-AMSK):
key label = "rfc4285-MN-HA-key"
application data = "HA Address"
output length = 128 bit
(key name: MN-HA-AMSK | EAP Session-ID)
Giaretta, et al. Expires - September 2006 [Page 9]
Internet-Draft AMSK for Mobile IPv6 March 2006
rfc4285 MN-AAA key (MN-AAA-AMSK):
key label = "rfc4285-MN-AAA-key"
application data = ""
output length = 128 bit
(key name: MN-AAA-AMSK | EAP Session-ID)
The actual key(s) to be derived by MN and AAA server depend on the
authentication method deployed by the operator (or imposed by
specific technologies). It should be possible on the operator side to
differentiate users' authentication method on profile basis.
The KDF does not include the home address in the application data
because in this way the MN can derive the AMSK even if it does not
know its home address yet. This is what might happen in some dynamic
home address assignment scenarios.
As specified in [12], the lifetime of keys calculated from key
material exported by EAP methods can not be longer than the lifetime
of the exported keying material. As a default choice the lifetime of
AMSK for MIPv6 is set equal to the lifetime of the EMSK.
Since the IKEv2-AMSK serves only for identity verification and not
for authentication or ciphering purposes, there might be no need to
re-generate the key at regular intervals. However, the IKEv2-AMSK
must be refreshed whenever a new EMSK is generated (i.e. during re-
authentication events). Since the MN-HA key is used to authenticate
BUs and BAs messages, there is a clear need to keep these keys fresh
and therefore to derive new keys periodically. This is discussed in
section 5.4.
Giaretta, et al. Expires - September 2006 [Page 10]
Internet-Draft AMSK for Mobile IPv6 March 2006
5. Open issues
AMSKs are still a work in progress in IETF and a good amount of study
is underway to standardize their generation and usage. For this
reason, this document leaves open some issues as input for HOAKY BoF
and others related WGs.
5.1 Key hierarchy
As depicted in Figure 3, the key hierarchy proposed in this document
implies that three different AMSKs are directly derived from the
EMSK. Another approach could be to define just one AMSK for MIPv6
that is used as root key for deriving other more specific keys (e.g.
MN-AAA-key or IKEv2-key). This may have the advantage that the EMSK
can be deleted just after the derivation of the AMSK for MIPv6.
Figure 4 depicts the resulting key hierarchy.
EMSK,MSK
|
AMSK-MIPv6
|
+----------------+-------------+
| | |
MN-AAA-key MN-HA-key IKEv2-key
Figure 4 - Alternative key hierarchy
5.2 Key length (and other key related parameters)
This specification doesn't address the problem of negotiating the key
length; this is a general issue for AMSKs and should be solved in a
generic way, not depending on the application that makes use of the
keys (e.g. Mobile IPv6 bootstrapping).
One very basic approach, applicable to some scenarios, is that the
operator pre-provisions the user equipment with the right parameters
(e.g. the right key lenght for a specific application).
If an explicit negotiation is needed, a possible approach could be
the one adopted in [17] that leverages the capability of some EAP
methods (e.g. EAP-SIM, EAP-FAST, etc.) to carry arbitrary parameters
during the authentication phase.
However, it is worthwhile noting that some applications require only
fixed length keys (e.g. MN-HA-AMSK and MN-AAA-AMSK for the MIPv6
Authentication Protocol) and for those applications this is not an
issue.
Giaretta, et al. Expires - September 2006 [Page 11]
Internet-Draft AMSK for Mobile IPv6 March 2006
5.3 rfc4285 SAs
This document addresses only the negotiation of the shared secret
among MN and HA (or AAA). Other parameters such as SPIs must be
negotiated through other mechanisms. As for the key length issue this
could be addressed by an explicit negotiation [17]. Another approach
might be the derivation of the SPI from the EAP keying hierarchy
itself.
5.4 Key Freshness
While not an issue for IKEv2 PSK authentication, for rfc2485-based
authentications the keys used to authenticate binding management
messages should be fresh and therefore periodically changed. This
document addresses only bootstrapping mechanisms and so the renewal
of keying material is out of scope. A suggested solution may be that
the MN-HA-AMSK is not used directly but a new derived key is
generated from it at each BU/BA completed exchange (e.g. exchanging
nonces in BUs and BAs).
5.5 Multiple EAP sessions
In some scenarios (e.g. multi-homed terminals) a MN may have more
than one active EAP session at the same time. Therefore, there is the
need to define criteria for deciding which session(s) are in charge
of generating AMSKs, and for which applications.
5.6 Identity management and key binding
A MN can be associated to several identities at the same time (e.g.
pseudonyms for identity privacy or temporary identities for EAP fast
reconnect techniques like [9]). The AAAH server must be aware of the
identity used by the MN in IKEv2 or rfc-4285 signaling. In pull model
this is needed to allow the AAAH server to select the correct key to
be delivered, upon requests, to the HA. In push model this is needed
to allow the AAAH server to proactively deliver to the HA the correct
MN identity information so that the HA can bind the subsequent
authentication requests to the right key.
Giaretta, et al. Expires - September 2006 [Page 12]
Internet-Draft AMSK for Mobile IPv6 March 2006
6. AAA-HA interface requirements
In order to fulfil the bootstrapping of MIPv6-related SAs, this
document adds/modifies some requirements for the HA-AAA interface
[20]:
- G1.4 should use MUST (instead of SHOULD): "The AAA-HA interface
MUST provide confidentiality since it may be used to transfer
keying material (e.g. shared key generated during EAP
authentication)"
- HAs must be able to fetch keys from AAA servers (pull approach)
- the AAAH server must be able to push a key into the HA (push
approach)
- key identifiers and lifetimes must be transferred alongside the
key
- in the request sent to the AAAH server in pull mode, HA must
specify the HA address known be the MN, so that the AAAH server
can derive the right key.
Giaretta, et al. Expires - September 2006 [Page 13]
Internet-Draft AMSK for Mobile IPv6 March 2006
7. Security Considerations
Sending AMSKs for Mobile IPv6 from the AAA server to the HA requires
that the protocol used for AAA-HA communication provides mutual
authentication, integrity/reply protection and confidentiality.
Moreover, since this document is strongly based on EAP [8] and the
EAP Keying Management Framework [12], additional security
considerations are bound to those valid for the EAP Keying Framework.
Giaretta, et al. Expires - September 2006 [Page 14]
Internet-Draft AMSK for Mobile IPv6 March 2006
8. IANA Considerations
This document does not require actions by the IANA.
Giaretta, et al. Expires - September 2006 [Page 15]
Internet-Draft AMSK for Mobile IPv6 March 2006
9. Acknowledgments
The authors would like to thank Alpesh Patel, Hannes Tschofenig, Rafa
Lopez and Antonio Skarmeta for reviewing the document and the
European Commission support in the co-funding of the ENABLE project,
where this work is partly being developed.
10. References
10.1 Normative References
[1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6",
RFC 3775, June 2004.
[2] Arkko, J., Devarapalli, V., Dupont, F., "Using IPsec to Protect
Mobile IPv6 Signaling between Mobile Nodes and Home Agents", RFC
3776, June 2004.
[3] Manner, J., Kojo, M. "Mobility Related Terminology", RFC 3753, June
2004
[4] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Lefkowetz,
"Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[5] A. Patel, K. Leung, M. Khalil, H. Akhtar, K. Chowdhury,
"Authentication Protocol for Mobile IPv6", RFC 4285, January 2006.
[6] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
December 2005.
[7] Manner, J., Kojo, M. "Mobility Related Terminology", RFC 3753, June
2004
[8] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., Levkowetz, H.,
"Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[9] Haverinen, H., Salowey, J. "Extensible Authentication Protocol
Method for Global System for Mobile Communications (GSM) Subscriber
Identity Modules (EAP-SIM)", RFC 4186, January 2006.
Giaretta, et al. Expires - September 2006 [Page 16]
Internet-Draft AMSK for Mobile IPv6 March 2006
10.2 Informative References
[10] Patel, A. et al. "Problem Statement for bootstrapping Mobile IPv6",
draft-ietf-mip6-bootstrap-ps-00 (work in progress), July 2004.
[11] K. Chowdhury, J. Bournelle, M. Nakhjiri, "Problem Statement for
AMSK", February 2006.
[12] Aboba, B., Simon, D., Arkko, J., Levkowetz, H., "EAP Key Management
Framework", draft-ietf-eap-keying-03(work in progress), July 2004.
[13] N.Cam-Winget, D. McGrew, J. Salowey, H.Zhou, "EAP Flexible
Authentication via Secure Tunneling (EAP-FAST)", draft-cam-winget-
eap-fast-00.txt (work in progress), February 2004
[14] Palekar, A. et al., "Protected EAP Protocol (PEAP) Version 2",
draft-josefsson-pppext-eap-tls-eap-08 (work in progress), July
2004.
[15] Haverinen, H. and J. Salowey, "Extensible Authentication Protocol
Method for GSM Subscriber Identity Modules (EAP-SIM)", draft-
haverinen-pppext-eap-sim-13 (work in progress), April 2004.
[16] Arkko, J. and H. Haverinen, "EAP-AKA Authentication", draft-arkko-
pppext-eap-aka-12 (work in progress), April 2004.
[17] Giaretta, G., Guardini, I., Demaria, E., Bournelle, J., Laurent-
Maknavicius, M., "MIPv6 Authorization and Configuration based on
EAP", draft-giaretta-mip6-authorization-eap-02 (work in progress),
October 2004.
[18] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for the
Integrated Scenario", draft-ietf-mip6-bootstrapping-integrated-dhc-
00 (work in progress), October 2005.
[19] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", draft-
ietf-mip6-bootstrapping-split-01 (work in progress), October 2005.
[20] Giaretta, G., Guardini, I., Demaria, E., Bournelle, J., Lopez, R.,
"Goals for AAA-HA interface ", draft-ietf-mip6-aaa-ha-goals-01
(work in progress), January 2006.
Giaretta, et al. Expires - September 2006 [Page 17]
Internet-Draft AMSK for Mobile IPv6 March 2006
Authors' Addresses
Gerardo Giaretta
Telecom Italia Lab
via G. Reiss Romoli, 274
10148 TORINO
Italy
Phone: +39 011 2286904
Email: gerardo.giaretta@telecomitalia.it
Ivano Guardini
Telecom Italia Lab
via G. Reiss Romoli, 274
10148 TORINO
Italy
Phone: +39 011 2285424
Email: ivano.guardini@telecomitalia.it
Elena Demaria
Telecom Italia Lab
via G. Reiss Romoli, 274
10148 TORINO
Italy
Phone: +39 011 2285403
Email: elena.demaria@telecomitalia.it
Michele La Monaca
Telecom Italia Lab
via G. Reiss Romoli, 274
10148 TORINO
Italy
Phone: +39 011 2285729
Email: michele.lamonaca@telecomitalia.it
Julien Bournelle
GET/INT
9 rue Charles Fourier
Evry 91011
France
Email: julien.bournelle@int-evry.fr
Maryline Laurent-Maknavicius
GET/INT
9 rue Charles Fourier
Evry 91011
France
Email: maryline.maknavicius@int-evry.fr
Giaretta, et al. Expires - September 2006 [Page 18]
Internet-Draft AMSK for Mobile IPv6 March 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.
Full Copyright Statement
Copyright (C) The Internet Society (2006). All Rights Reserved.
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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Giaretta, et al. Expires - September 2006 [Page 19] | PAFTECH AB 2003-2026 | 2026-04-22 06:32:37 |