One document matched: draft-giaretta-mip6-amsk-02.txt
Differences from draft-giaretta-mip6-amsk-01.txt
MIP6 Working Group G. Giaretta
Internet Draft I. Guardini
Expires: April 2007 E. Demaria
M. La Monaca
Telecom Italia
J. Bournelle
M. Laurent-Maknavicius
GET/INT
October 2006
Application Master Session Key (AMSK) for Mobile IPv6
<draft-giaretta-mip6-amsk-02.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 April 17, 2007.
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 can be
useful to leverage this keying material to derive usage specific
keys that can be used to authenticate users or protect information
exchange by other applications or services.For this purpose [10]
proposes to derive root keys for each usage application and, then,
child keys to actual be used.
This document defines how to generate a Usage Specific Root Key
(USRK) and a series of Application Master Session Keys (AMSKs)
specific to Mobile IPv6 service. These AMSKs can be used by Mobile
Node and Home Agent to bootstrap Mobile IPv6 protocol operation.
Giaretta, et al. Expires - April 2006 [Page 1]
Internet-Draft AMSK for Mobile IPv6 October 2006
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..........................6
4. Key derivation.............................................10
4.1 Mobile IPv6 USRK derivation.............................10
4.2 Mobile IPv6 AMSKs derivation............................10
4.3 Lifetimes...............................................11
5. Open issues................................................12
5.1 Key length (and other key related parameters)...........12
5.2 rfc4285 SAs.............................................12
5.3 Key Freshness...........................................12
5.4 Multiple EAP sessions...................................12
5.5 Identity management and key binding.....................12
6. AAA-HA interface requirements..............................14
7. Security Considerations....................................15
8. IANA Considerations........................................16
9. Acknowledgments............................................17
10. References.................................................17
10.1 Normative References..................................17
10.2 Informative References................................17
Authors' Addresses..............................................19
Intellectual Property Statement.................................20
Giaretta, et al. Expires - April 2007 [Page 2]
Internet-Draft AMSK for Mobile IPv6 October 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 [11]. 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 [13]. In particular [10] specifies a mechanism for
deriving cryptographically separate root keys from the EMSK,
called Usage Specific Root Keys (USRK) in order to create a set of
keys for usage specific needs.
This document defines how to generate EAP derived key (USRK)
specific for Mobile IPv6 bootstrapping. In addition, it defines
how to derive application specific keys (AMSKs) 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 - April 2007 [Page 3]
Internet-Draft AMSK for Mobile IPv6 October 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 [13].
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.
USRK Usage Specific Root Key
Keys derived from the EMSK which are cryptographically
separate from each other.
AMSK Application Master Session Key
Keys derived from the USRK 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.
Giaretta, et al. Expires - April 2007 [Page 4]
Internet-Draft AMSK for Mobile IPv6 October 2006
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 - April 2007 [Page 5]
Internet-Draft AMSK for Mobile IPv6 October 2006
3. Applicability Statement
The Mobile IPv6 bootstrapping problem statement [11] 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 [19]
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 a key derived from EAP key hierarchy
and 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.
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 a
key derived from EAP key hierarchy and 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
Giaretta, et al. Expires - April 2007 [Page 6]
Internet-Draft AMSK for Mobile IPv6 October 2006
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
a key derived from EAP key hierarchy and 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 - April 2007 [Page 7]
Internet-Draft AMSK for Mobile IPv6 October 2006
EAP PEER EAP-AUTH EAP-AUTH Server
Home
MN NAS Server
Agent
| |
|
| EAP session |
|
|<----------------------------->|
|
| |
|
| o o o |
|
| |
|
| | Access-Accept |
|
U A| | EAP Success, MSK |
|
S M| EAP Succ. |<------------------+
|
R S|<----------| \ ------------
|
K K| | USRK |
|
s| |generation |
|
| ------------
|
| Binging Update / IKEv2 IKE_AUTH
|
|--------------------------------------------------------------
>|
|
|
| | "Key-Request, MN identity"
|
| |<-----------------------------
-|
| | "keying material"
|
| | -----------------------------
>|
| ----------- /
|
| | AMSKs |
|
| |generation |
|
| -----------
|
Figure 1 - Pull model message flow
EAP PEER EAP-AUTH EAP-AUTH Server
Home
MN NAS Server
Agent
| |
|
| EAP session |
|
Giaretta, et al. Expires - April 2007 [Page 8]
Internet-Draft AMSK for Mobile IPv6 October 2006
|<----------------------------->|
|
| |
|
| o o o |
|
| |
|
| | Access-Accept |
|
U A| | EAP Success, MSK | "Keying material, MN
identity"|
S M| EAP Succ. |<------------------+------------------------------
>|
R S|<----------| \ ------------
|
K K| | USRK | ----------- /
|
s| |generation | | AMSKs |
|
| ------------ |generation |
|
| -----------
|
| Binging Update / IKEv2 IKE AUTH
|
|--------------------------------------------------------------
>|
Figure 2 - Push model message flow
Giaretta, et al. Expires - April 2007 [Page 9]
Internet-Draft AMSK for Mobile IPv6 October 2006
4. Key derivation
The key hierarchy proposed in this document is depicted in Figure
3. Just one key (MIP6-USRK) is directly derived from the EMSK.
Three different keys are then generated from the MIP6-USRK: IKEv2-
AMSK, MN-HA-AMSK and MN-AAA-AMSK. The basic assumption is that the
MIP6-USRK is exported by the EAP server to the AAA server that
sends this key to the HA; the other keys are then derived directly
from the USRK by the HA of the MSP.
EMSK
|
MIP6-USRK
|
+----------------------------------+
| | |
MN-AAA-AMSK MN-HA-AMSK IKEv2-AMSK
Figure 3 - Proposed key hierarchy
4.1 Mobile IPv6 USRK derivation
Mobile IPv6 USRK (MIP6-USRK) is derived through the general key
derivation function (KDF) specified in [10]. The KDF is based on a
pseudo random function shown below:
KDF = PRF(key, data)
where:
PRF = HMAC-SHA-256
key = EMSK
data = label + "\0" + op-data + length
label = MIPv6-USRK-key
op-data = EAP Session-ID
length = 128 bit
"\0" = is a NUL byte (0x00 in hex)
+ denotes concatenation
Key name = PRF-64 (EAP Session-ID, key-label)
Where PRF-64 is the first 64 bits from the output.
4.2 Mobile IPv6 AMSKs derivation
Based on Mobile IPv6 USRK, the keys for Mobile IPv6 operations
(IKEv2-AMSK, MN-HA-AMSK, and MN-AAA-AMSK) can be generated. These
keys are derived as follows:
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-SHA-256
K = USRK-MIPv6
L = key label
D = application data
O = output length
S = L | " " | D | O
The application specific parameters are set as follows:
Giaretta, et al. Expires - April 2007 [Page 10]
Internet-Draft AMSK for Mobile IPv6 October 2006
IKEv2 Pre-shared key AMSK (IKEv2-AMSK):
key label = "MIPv6-IKEv2-key"
application data = "HA Address"
output length = variable (default 128)
(key name = PRF-64(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 = PRF-64(MN-HA-AMSK | EAP Session-ID)
rfc4285 MN-AAA key (MN-AAA-AMSK):
key label = "rfc4285-MN-AAA-key"
application data = ""
output length = 128 bit
(key name = PRF-64(MN-AAA-AMSK | EAP Session-ID)
The actual key(s) to be derived by MN and HA 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.
4.3 Lifetimes
As specified in [10] the lifetime of USRK keys must be equal to
the lifetime of the EMSK. Lifetime of child keys, instead, can be
different then root key’s lifetime and its specification is left
to usage definition.
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. For this reason its
lifetime is set equal to the MIP6-USRK lifetime.
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.3.
Obviously all keys must be refreshed whenever a new EMSK is
generated (i.e. during re-authentication events).
Giaretta, et al. Expires - April 2007 [Page 11]
Internet-Draft AMSK for Mobile IPv6 October 2006
5. Open issues
The usage of EAP-derived keying material is still a work in
progress in IETF and a good amount of study is underway to
standardize generation and usage for keys generated from the EMSK.
For this reason, this document leaves open some issues as input
for HOKEY WG and others related WGs.
5.1 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 [18] 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.
5.2 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 [18]. Another
approach might be the derivation of the SPI from the EAP keying
hierarchy itself.
5.3 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 a new MN-HA-AMSK is generated at each BU/BA completed
exchange (e.g. exchanging nonces in BUs and BAs).
5.4 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.5 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
Giaretta, et al. Expires - April 2007 [Page 12]
Internet-Draft AMSK for Mobile IPv6 October 2006
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 - April 2007 [Page 13]
Internet-Draft AMSK for Mobile IPv6 October 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
[21]:
- 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 - April 2007 [Page 14]
Internet-Draft AMSK for Mobile IPv6 October 2006
7. Security Considerations
Sending USRK 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 [13], additional security
considerations are bound to those valid for the EAP Keying
Framework.
Giaretta, et al. Expires - April 2007 [Page 15]
Internet-Draft AMSK for Mobile IPv6 October 2006
8. IANA Considerations
This document does not require actions by the IANA.
Giaretta, et al. Expires - April 2007 [Page 16]
Internet-Draft AMSK for Mobile IPv6 October 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.
[10] Salowey J., Dondeti L., Narayanan V., Nakhjiri M.,
"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.
10.2 Informative References
[11] Patel, A. et al. "Problem Statement for bootstrapping Mobile
IPv6", draft-ietf-mip6-bootstrap-ps-00 (work in progress), July
2004.
Giaretta, et al. Expires - April 2007 [Page 17]
Internet-Draft AMSK for Mobile IPv6 October 2006
[12] K. Chowdhury, J. Bournelle, M. Nakhjiri, "Problem Statement for
AMSK", February 2006.
[13] Aboba, B., Simon, D., Arkko, J., Levkowetz, H., "EAP Key
Management Framework", draft-ietf-eap-keying-14(work in
progress), June 2006.
[14] 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
[15] Palekar, A. et al., "Protected EAP Protocol (PEAP) Version 2",
draft-josefsson-pppext-eap-tls-eap-08 (work in progress), July
2004.
[16] 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.
[17] Arkko, J. and H. Haverinen, "EAP-AKA Authentication", draft-
arkko-pppext-eap-aka-12 (work in progress), April 2004.
[18] 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.
[19] 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.
[20] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario",
draft- ietf-mip6-bootstrapping-split-01 (work in progress),
October 2005.
[21] 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 - April 2007 [Page 18]
Internet-Draft AMSK for Mobile IPv6 October 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 - April 2007 [Page 19]
Internet-Draft AMSK for Mobile IPv6 October 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 - April 2007 [Page 20] | PAFTECH AB 2003-2026 | 2026-04-22 06:32:37 |