One document matched: draft-arkko-eap-aka-kdf-00.txt
Network Working Group J. Arkko
Internet-Draft V. Lehtovirta
Updates: 4187 (if approved) Ericsson
Intended status: Informational P. Eronen
Expires: January 8, 2009 Nokia
July 7, 2008
Improved Extensible Authentication Protocol Method for 3rd Generation
Authentication and Key Agreement (EAP-AKA')
draft-arkko-eap-aka-kdf-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 January 8, 2009.
Arkko, et al. Expires January 8, 2009 [Page 1]
Internet-Draft EAP-AKA' July 2008
Abstract
This specification defines a new EAP method, EAP-AKA', a small
revision of the EAP-AKA method. The change is a new key derivation
function that binds the name of the access network to the keys
derived within the method. As a result, it becomes possible to
authenticate the network name. The new key derivation mechanism has
been defined in 3GPP. This specification allows its use in EAP in an
interoperable manner.
This specification also updates RFC 4187 EAP-AKA to add support for
preventing bidding down attacks between itself and EAP-AKA'.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. EAP-AKA' . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. The AT_KDF_INPUT Attribute . . . . . . . . . . . . . . . . 5
2.2. AT_KDF . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Key Generation . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Hash Function Update . . . . . . . . . . . . . . . . . . . 9
3. Bidding Down Prevention for EAP-AKA . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Changes from RFC 4187 . . . . . . . . . . . . . . . . 17
Appendix B. Importance of Explicit Negotiation . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Arkko, et al. Expires January 8, 2009 [Page 2]
Internet-Draft EAP-AKA' July 2008
1. Introduction
This specification defines a new Extensible Authentication Protocol
(EAP)[RFC3748] method, EAP-AKA', a small revision of the EAP-AKA
method originally defined in [RFC4187]. What is new in EAP-AKA' is
that it has a new key derivation function specified in [3GPP.33.402].
This function binds the name of the access network to the keys
derived within the method. As a result, it becomes possible to
authenticate the network name, limiting the effects of compromised
nodes and keys. This specification defines the EAP encapsulation for
AKA when the new key derivation mechanism is in use.
3GPP has defined a number of applications for the revised AKA
mechanism, some based on native encapsulation of AKA over 3GPP radio
access networks and others based on the use of EAP.
For making the new key derivation mechanisms usable in EAP-AKA
additional protocol mechanisms are necessary. Given that RFC 4187
calls for the use of CK (the encryption key) and IK (the integrity
key) from AKA directly, existing implementations continue to use
these. Any change of the key derivation must be unambiguous to both
sides in the protocol. That is, it must not be possible to
accidentally connect old equipment to new equipment and get the key
derivation wrong or attempt to use wrong keys without getting a
proper error message.
This specification therefore introduces a variant of the EAP-AKA
method, called EAP-AKA'. This method can employ the derived keys CK'
and IK' from the 3GPP specification but it is otherwise equivalent to
RFC 4187. Given that a different EAP method Type value is used for
EAP-AKA and EAP-AKA', a mutually supported method may be negotiated
using the standard mechanisms in EAP [RFC3748].
Editor's Note: A number of other possible ways to use the new key
derivation functions have been proposed. These include
configuration and reliance on a particular domain employing only
the new functions. Appendix B explains why these approaches lead
to severe interoperability problems and why it is important to be
explicit about the change of semantics in protocol design.
The rest of this specification is structured as follows. Section 2
defines the EAP-AKA' method. Section 3 adds support to EAP-AKA to
prevent bidding down attacks from EAP-AKA'. Section 4 explains the
security differences between EAP-AKA and EAP-AKA'. Section 5
describes the IANA considerations and Appendix A explains what
updates to RFC 4187 EAP-AKA have been made in this specification.
Arkko, et al. Expires January 8, 2009 [Page 3]
Internet-Draft EAP-AKA' July 2008
2. EAP-AKA'
EAP-AKA' is a new EAP method that follows EAP-AKA specification
[RFC4187] in all other respects except the following:
o It uses the Type code TBD1 BY IANA, not 23 which is used by EAP-
AKA.
o It carries the AT_KDF_INPUT attribute, as defined in Section 2.1
to ensure that both parties know the name of the access network.
o It calculates the Master Key (MK) as defined in Section 2.3, not
as defined in EAP-AKA.
o It uses the optional AT_KDF attribute as defined in Section 2.2 to
control possible future key derivation function changes.
Figure 1 shows an example of the authentication process. Each
message AKA'-Challenge and so on represents the corresponding message
from EAP-AKA, but with EAP-AKA' Type code. The definition of these
messages, along with the definition of attributes AT_RAND, AT_AUTN,
AT_MAC, and AT_RES can be found from [RFC4187].
Arkko, et al. Expires January 8, 2009 [Page 4]
Internet-Draft EAP-AKA' July 2008
Peer Server
| EAP-Request/Identity |
|<------------------------------------------------------|
| |
| EAP-Response/Identity |
| (Includes user's NAI) |
|------------------------------------------------------>|
| +-------------------------------+
| | Server runs AKA' algorithms, |
| | generates AT_RAND and AT_AUTN.|
| | For creating AT_MAC, the |
| | server employs CK' and IK'. |
| +-------------------------------+
| EAP-Request/AKA'-Challenge |
| (AT_RAND, AT_AUTN, AT_KDF_INPUT, AT_MAC)|
|<------------------------------------------------------|
+-------------------------------------+ |
| Peer runs AKA' algorithms, | |
| verifies AT_AUTN and AT_MAC, derives| |
| AT_RES and session keys. Again, for | |
| verifying AT_MAC and creating | |
| AT_RES, the peer uses CK' and IK' | |
+-------------------------------------+ |
| EAP-Response/AKA'-Challenge |
| (AT_RES, AT_MAC) |
|------------------------------------------------------>|
| +--------------------------------+
| | Server checks the given AT_RES,|
| | and MAC and finds them correct.|
| +--------------------------------+
| EAP-Success |
|<------------------------------------------------------|
Figure 1: EAP-AKA' Authentication Process
2.1. The AT_KDF_INPUT Attribute
The format of the AT_KDF_INPUT attribute is shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_KDF_INPUT | Length | Actual Network Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Network Name .
. .
| |
Arkko, et al. Expires January 8, 2009 [Page 5]
Internet-Draft EAP-AKA' July 2008
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are as follows:
AT_KDF_INPUT
This is set to TBD2 BY IANA.
Length
The length of the attribute, calculated as defined in [RFC4187]
Section 8.1.
Actual Network Name Length
This a 2-byte actual length field, needed due to the requirement
that previous field is expressed in multiples of 4 bytes per the
usual EAP-SIM and EAP rules. The Actual Network Name Length field
provides the length of the Network Name in bytes.
Network Name
This field contains the network name of the access network for
which the authentication is being performed. The name does not
include any terminating null characters. Because the length of
the entire attribute must be a multiple of 4 bytes, the sender
pads the name with zero bytes when necessary.
Only the server sends the AT_KDF_INPUT attribute. The peer SHOULD
check the received value against its own understanding of the network
name. Upon detecting a discrepancy, the peer MAY either log an error
and continue, or fail the authentication process.
The Network Name field contains an octet string. This string MUST be
constructed as specified in [3GPP.23.003]. For network types where
this reference does not provide an instruction on how to construct
the name, the empty octet string SHOULD be used.
Editor's Note: This 3GPP specification is still being worked on.
It is assumed that the specification ensures that conflicts
potentially arising from using the same name in different types of
networks are avoided. It is also assumed that the 3GPP
specification will have detailed rules about how a client can
determine these based on information available to the client, such
as the type of protocol used to attach to the network, beacons
sent out by the network, and so on. Information that the client
cannot directly observe (such as the type or version of the home
Arkko, et al. Expires January 8, 2009 [Page 6]
Internet-Draft EAP-AKA' July 2008
network) should not be used by this algorithm.
2.2. AT_KDF
AT_KDF is an optional attribute that the server MAY use when it
wishes to employ a specific key derivation function. This is useful
for future evolution of the key derivation functions.
The format of the AT_KDF attribute is shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_KDF | Length | Key Derivation Function |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are as follows:
AT_KDF
This is set to TBD3 BY IANA.
Length
The length of the attribute, MUST be set to 1.
Key Derivation Function
An enumerated value representing the key derivation function that
the server (or peer) wishes to use. Value 1 represents RFC 4187
key derivation, i.e., fallback to EAP-AKA functionality. Value 2
represents the default key derivation function for EAP-AKA', i.e.,
employing CK' and IK' as defined in Section 2.3.
Servers MAY choose to send one or more AT_KDF attributes in the EAP-
Request/AKA'-Challenge message. The first of these attributes
represents the desired function and the other ones are acceptable
alternatives, the most desired alternative being the second
attribute.
Upon receiving this attribute, if the peer supports and is willing to
use the key derivation function indicated by the first attribute, the
function is taken into use and no further action is necessary.
However, if the peer does not support this function or is unwilling
to use it, it responds with the EAP-Response/AKA'-Challenge message
that contains only one attribute, AT_KDF with the value set to the
selected alternative. If there is no suitable alternative, the peer
Arkko, et al. Expires January 8, 2009 [Page 7]
Internet-Draft EAP-AKA' July 2008
behaves as if AT_MAC had been incorrect and authentication fails.
Upon receiving an EAP-Response/AKA'-Challenge with AT_KDF from the
peer, the server checks that the alternative was in its offer. If
not, it behaves as if AT_MAC of the response had been incorrect and
fails the authentication. Otherwise, the server re-sends the EAP-
Response/AKA'-Challenge message, but moves the selected alternative
to the beginning of the list of AT_KDF attributes.
When the peer receives the new EAP-Request/AKA'-Challenge message, it
MUST check that requested change, and only the requested change
occurred in the list of AT_KDF attributes. If yes, it continues. If
not, it behaves as if AT_MAC had been incorrect and fails the
authentication.
2.3. Key Generation
Both the peer and server MUST derive the Master Key (MK) from
underlying AKA values and the identity, as follows.
AT_KDF set to 1
MK is as defined in [RFC4187].
AT_KDF not present or set to 2
MK is as follows:
MK = SHA1(Identity|IK'|CK')
Here SHA1 and Identity are as specified in [RFC4187] and IK' and
CK' are derived as specified in [3GPP.33.402]. The functions that
derive IK' and CK' take the following parameters: CK and IK
produced by the AKA algorithm and value of the Network Name field
(without length or padding) from AT_KDF_INPUT as the access
network identity.
AT_KDF is present and has any other value
Future variations of key derivation functions may be defined, and
they will be represented by new values of AT_KDF. If the peer
does not recognize the value it cannot calculate the keys and
behaves as explained in Section 2.2.
If the peer supports a given key derivation function but is unwilling
to perform it for policy reasons, it refuses to calculate the keys
and behaves as explained in Section 2.2.
Arkko, et al. Expires January 8, 2009 [Page 8]
Internet-Draft EAP-AKA' July 2008
2.4. Hash Function Update
Given that we are defining a new method, it would potentially be a
convenient time to introduce a change of the hash functions from
those used in EAP-AKA (SHA1) to SHA256 which is used in new 3GPP
systems. Would this be desirable?
Arkko, et al. Expires January 8, 2009 [Page 9]
Internet-Draft EAP-AKA' July 2008
3. Bidding Down Prevention for EAP-AKA
As discussed in [RFC3748], negotiation of methods within EAP is
insecure. That is, a man-in-the-middle attacker may force the
endpoints to use a method that is not the strongest one they both
support. This is a problem, as we expect EAP-AKA and EAP-AKA' to be
negotiated via EAP.
In order to prevent such attacks, this specification specifies a new
mechanism for EAP-AKA that allows the endpoints to securely discover
the capabilities of each other. This mechanism comes in the form of
the AT_BIDDING attribute. This allows both endpoints to communicate
their desire and support for EAP-AKA' when exchanging EAP-AKA
messages. This attribute is not included in EAP-AKA' messages as
defined in this RFC. If during the authentication process it is
discovered that both endpoints would have been able to use EAP-AKA',
the authentication process SHOULD be aborted, as a bidding down
attack may have happened.
The format of the AT_BIDDING attribute is shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_BIDDING | Length |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are as follows:
AT_BIDDING
This is set to TBD4 BY IANA.
Length
The length of the attribute, MUST be set to 1.
D
This bit is set to 1 if the sender does support EAP-AKA', is
willing to use it, and prefers it over EAP-AKA. Otherwise it
should be set to 0.
Reserved
This field MUST be set to zero when sent and ignored on receipt.
Arkko, et al. Expires January 8, 2009 [Page 10]
Internet-Draft EAP-AKA' July 2008
The server sends this attribute in the EAP-Request/AKA-Challenge
message. The peer compares the received value to its own
capabilities. If it turns out that both the server and peer would
have been able to use EAP-AKA' and preferred it over EAP-AKA, the
peer behaves as if AT_MAC had been incorrect, and fails the
authentication.
Arkko, et al. Expires January 8, 2009 [Page 11]
Internet-Draft EAP-AKA' July 2008
4. Security Considerations
A summary of the security properties of EAP-AKA' follows. As there
has been only a minor change in the method, most of the security
properties are unchanged from EAP-AKA.
Protected ciphersuite negotiation
The ciphersuite negotiation mechanisms of EAP-AKA are also present
in EAP-AKA'. Refer to [RFC4187] Section 12 for further details.
However, EAP-AKA' adds a new negotiation mechanism for selecting
the key derivation function that feeds CK' and IK' into MK. This
mechanism is secure against bidding down attacks.
Mutual authentication
The properties of EAP-AKA' are exactly as those of EAP-AKA in this
respect. Refer to [RFC4187] Section 12 for further details.
Integrity protection
The properties of EAP-AKA' are exactly as those of EAP-AKA in this
respect. Refer to [RFC4187] Section 12 for further details.
Replay protection
The properties of EAP-AKA' are exactly as those of EAP-AKA in this
respect. Refer to [RFC4187] Section 12 for further details.
Confidentiality
The properties of EAP-AKA' are exactly as those of EAP-AKA in this
respect. Refer to [RFC4187] Section 12 for further details.
Key derivation
The key derivation mechanisms of EAP-AKA are also present in EAP-
AKA'. Refer to [RFC4187] Section 12 for further details.
However, EAP-AKA' adds an additional layer of key derivation
functions within itself. This does not affect the type of keys
the method exports. However, the additional functions make it
harder to use compromised keys in a different context.
Key strength
The properties of EAP-AKA' are exactly as those of EAP-AKA in this
respect, on the assumption that key derivation functions do not
change the strength of the keys. This is currently the case with
Arkko, et al. Expires January 8, 2009 [Page 12]
Internet-Draft EAP-AKA' July 2008
the functions defined in [3GPP.33.402]. Refer to [RFC4187]
Section 12 for further details.
Dictionary attack resistance
The properties of EAP-AKA' are exactly as those of EAP-AKA in this
respect. Refer to [RFC4187] Section 12 for further details.
Fast reconnect
The properties of EAP-AKA' are exactly as those of EAP-AKA in this
respect. Refer to [RFC4187] Section 12 for further details. Note
that implementations MUST prevent performing a fast reconnect
across method types.
Cryptographic binding
Note that this term refers to a very specific form of binding,
something that is performed between two layers of authentication.
It is not the same as the binding to a particular network name.
The properties of EAP-AKA' are exactly as those of EAP-AKA in this
respect, i.e., as it is not a tunnel method this property is not
applicable to it. Refer to [RFC4187] Section 12 for further
details.
Session independence
The properties of EAP-AKA' are exactly as those of EAP-AKA in this
respect. Refer to [RFC4187] Section 12 for further details.
Fragmentation
The properties of EAP-AKA' are exactly as those of EAP-AKA in this
respect. Refer to [RFC4187] Section 12 for further details.
Channel binding
EAP-AKA' provides a simple form of channel binding.
Arkko, et al. Expires January 8, 2009 [Page 13]
Internet-Draft EAP-AKA' July 2008
5. IANA Considerations
EAP-AKA' has the EAP Type value TBD1 BY IANA. Per [RFC3748] Section
6.2, this allocation can be made with Designated Expert and
Specification Required.
EAP-AKA' shares its attribute space and message Subtypes, with EAP-
SIM [RFC4186] and EAP-AKA [RFC4186].
However, a new Attribute Type value (TBD2) in the non-skippable range
needs to be assigned for AT_KDF_INPUT (Section 2.1).
Also, a new Attribute Type value (TBD3) in the non-skippable range
needs to be assigned for AT_KDF (Section 2.2). IANA also needs to
create a registry for EAP-AKA' KDF Type values. The initial contents
of this registry are given below; new values can be created through
Specification Required policy [RFC5226].
Value Description Reference
--------- ---------------------- ---------------
0 Reserved
1 EAP-AKA with CK/IK [this document]
2 EAP-AKA' with CK'/IK' [this document]
3-65535 Unassigned
Finally, a new Attribute Type value (TBD4) in the skippable range
needs to be assigned for AT_BIDDING (Section 3).
Arkko, et al. Expires January 8, 2009 [Page 14]
Internet-Draft EAP-AKA' July 2008
6. Acknowledgments
The authors would like to thank Guenther Horn, Joe Salowey, Mats
Naslund, and Stefan Rommer for interesting discussions in this
problem space.
Arkko, et al. Expires January 8, 2009 [Page 15]
Internet-Draft EAP-AKA' July 2008
7. References
7.1. Normative References
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication
Protocol Method for 3rd Generation Authentication and Key
Agreement (EAP-AKA)", RFC 4187, January 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[3GPP.23.003]
3GPP, "3rd Generation Partnership Project; Technical
Specification Group Core Network and Terminals; Numbering,
addressing and identification (Release 8)", 3GPP Draft
Technical Specification 23.003 v 8.0.0, June 2008.
[3GPP.33.402]
3GPP, "3GPP System Architecture Evolution (SAE); Security
aspects of non-3GPP accesses; Release 8", 3GPP Draft
Technical Specification 33.402 v 8.0.0, June 2008.
7.2. Informative References
[RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication
Protocol Method for Global System for Mobile
Communications (GSM) Subscriber Identity Modules (EAP-
SIM)", RFC 4186, January 2006.
[RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity
Selection Hints for the Extensible Authentication Protocol
(EAP)", RFC 4284, January 2006.
[RFC5113] Arkko, J., Aboba, B., Korhonen, J., and F. Bari, "Network
Discovery and Selection Problem", RFC 5113, January 2008.
Arkko, et al. Expires January 8, 2009 [Page 16]
Internet-Draft EAP-AKA' July 2008
Appendix A. Changes from RFC 4187
The changes to RFC 4187 relate only to the bidding down prevention
support defined Section 3.
Arkko, et al. Expires January 8, 2009 [Page 17]
Internet-Draft EAP-AKA' July 2008
Appendix B. Importance of Explicit Negotiation
Choosing between the traditional and revised AKA key derivation
functions is easy when their use is unambiguously tied to a
particular radio access network, e.g LTE as defined by 3GPP or eHRPD
as defined by 3GPP2. There is no possibility for interoperability
problems if this radio access network is always used in conjunction
with new protocols that cannot be mixed with the old ones; clients
will always know whether they are connecting to the old or new
system.
However, using the new key derivation functions over EAP introduces
several degrees of separation, making the choice of the correct key
derivation functions much harder. Many different types of networks
employ EAP. Most of these networks have no means to carry any
information about what is expected from the authentication process.
EAP itself is severely limited in carrying any additional
information, as noted in [RFC4284] [RFC5113]. Even if these networks
or EAP were extended to carry additional information, it would not
affect millions of deployed access networks and clients attaching to
them.
Simply changing the key derivation functions that EAP-AKA [RFC4187]
uses would cause interoperability problems with all of the existing
implementations. Perhaps it would be possible to employ strict
separation into domain names that should be used by the new clients
and networks. Only these new devices would then employ the new key
derivation mechanism. While this can be made to work for specific
cases, it would be an extremely brittle mechanism, ripe to result in
problems whenever client configuration, routing of authentication
requests, or server configuration does not match expectations. It
also does not help to assume that the EAP client and server are
running a particular release of 3GPP network specifications. Network
vendors often provide features from the future releases early or do
not provide all features of the current release. And obviously,
there are many EAP and even some EAP-AKA implementations that are not
bundled with the 3GPP network offerings. In general, these
approaches are expected to lead to hard-to-diagnose problems and
increased support calls.
Arkko, et al. Expires January 8, 2009 [Page 18]
Internet-Draft EAP-AKA' July 2008
Authors' Addresses
Jari Arkko
Ericsson
Jorvas 02420
Finland
Email: jari.arkko@piuha.net
Vesa Lehtovirta
Ericsson
Jorvas 02420
Finland
Email: vesa.lehtovirta@ericsson.com
Pasi Eronen
Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
Finland
Email: pasi.eronen@nokia.com
Arkko, et al. Expires January 8, 2009 [Page 19]
Internet-Draft EAP-AKA' July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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.
Arkko, et al. Expires January 8, 2009 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-23 03:32:15 |