730 lines
26 KiB
Plaintext
730 lines
26 KiB
Plaintext
|
||
|
||
|
||
Network Working Group P. Eronen
|
||
Internet-Draft Nokia
|
||
Expires: December 28, 2006 H. Tschofenig
|
||
Siemens
|
||
June 26, 2006
|
||
|
||
|
||
Extension for EAP Authentication in IKEv2
|
||
draft-eronen-ipsec-ikev2-eap-auth-05.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 December 28, 2006.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (2006).
|
||
|
||
Abstract
|
||
|
||
IKEv2 specifies that EAP authentication must be used together with
|
||
public key signature based responder authentication. This is
|
||
necessary with old EAP methods that provide only unilateral
|
||
authentication using, e.g., one-time passwords or token cards.
|
||
|
||
This document specifies how EAP methods that provide mutual
|
||
authentication and key agreement can be used to provide extensible
|
||
|
||
|
||
|
||
Eronen & Tschofenig Expires December 28, 2006 [Page 1]
|
||
|
||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
||
|
||
|
||
responder authentication for IKEv2 based on other methods than public
|
||
key signatures.
|
||
|
||
|
||
1. Introduction
|
||
|
||
The Extensible Authentication Protocol (EAP), defined in [4], is an
|
||
authentication framework which supports multiple authentication
|
||
mechanisms. Today, EAP has been implemented at end hosts and routers
|
||
that connect via switched circuits or dial-up lines using PPP [13],
|
||
IEEE 802 wired switches [9], and IEEE 802.11 wireless access points
|
||
[11].
|
||
|
||
One of the advantages of the EAP architecture is its flexibility.
|
||
EAP is used to select a specific authentication mechanism, typically
|
||
after the authenticator requests more information in order to
|
||
determine the specific authentication method to be used. Rather than
|
||
requiring the authenticator (e.g., wireless LAN access point) to be
|
||
updated to support each new authentication method, EAP permits the
|
||
use of a backend authentication server which may implement some or
|
||
all authentication methods.
|
||
|
||
IKEv2 [3] is a component of IPsec used for performing mutual
|
||
authentication and establishing and maintaining security associations
|
||
for IPsec ESP and AH. In addition to supporting authentication using
|
||
public key signatures and shared secrets, IKEv2 also supports EAP
|
||
authentication.
|
||
|
||
IKEv2 provides EAP authentication since it was recognized that public
|
||
key signatures and shared secrets are not flexible enough to meet the
|
||
requirements of many deployment scenarios. By using EAP, IKEv2 can
|
||
leverage existing authentication infrastructure and credential
|
||
databases, since EAP allows users to choose a method suitable for
|
||
existing credentials, and also makes separation of the IKEv2
|
||
responder (VPN gateway) from the EAP authentication endpoint (backend
|
||
AAA server) easier.
|
||
|
||
Some older EAP methods are designed for unilateral authentication
|
||
only (that is, EAP peer to EAP server). These methods are used in
|
||
conjunction with IKEv2 public key based authentication of the
|
||
responder to the initiator. It is expected that this approach is
|
||
especially useful for "road warrior" VPN gateways that use, for
|
||
instance, one-time passwords or token cards to authenticate the
|
||
clients.
|
||
|
||
However, most newer EAP methods, such as those typically used with
|
||
IEEE 802.11i wireless LANs, provide mutual authentication and key
|
||
agreement. Currently, IKEv2 specifies that also these EAP methods
|
||
|
||
|
||
|
||
Eronen & Tschofenig Expires December 28, 2006 [Page 2]
|
||
|
||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
||
|
||
|
||
must be used together with public key signature based responder
|
||
authentication.
|
||
|
||
In some environments, requiring the deployment of PKI for just this
|
||
purpose can be counterproductive. Deploying new infrastructure can
|
||
be expensive, and it may weaken security by creating new
|
||
vulnerabilities. Mutually authenticating EAP methods alone can
|
||
provide a sufficient level of security in many circumstances, and
|
||
indeed, IEEE 802.11i uses EAP without any PKI for authenticating the
|
||
WLAN access points.
|
||
|
||
This document specifies how EAP methods that offer mutual
|
||
authentication and key agreement can be used to provide responder
|
||
authentication in IKEv2 completely based on EAP.
|
||
|
||
1.1. 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 [2].
|
||
|
||
|
||
2. Scenarios
|
||
|
||
In this section we describe two scenarios for extensible
|
||
authentication within IKEv2. These scenarios are intended to be
|
||
illustrative examples rather than specifying how things should be
|
||
done.
|
||
|
||
Figure 1 shows a configuration where the EAP and the IKEv2 endpoints
|
||
are co-located. Authenticating the IKEv2 responder using both EAP
|
||
and public key signatures is redundant. Offering EAP based
|
||
authentication has the advantage that multiple different
|
||
authentication and key exchange protocols are available with EAP with
|
||
different security properties (such as strong password based
|
||
protocols, protocols offering user identity confidentiality and many
|
||
more). As an example it is possible to use GSS-API support within
|
||
EAP [6] to support Kerberos based authentication which effectively
|
||
replaces the need for KINK [14].
|
||
|
||
+------+-----+ +------------+
|
||
O | IKEv2 | | IKEv2 |
|
||
/|\ | Initiator |<---////////////////////--->| Responder |
|
||
/ \ +------------+ IKEv2 +------------+
|
||
User | EAP Peer | Exchange | EAP Server |
|
||
+------------+ +------------+
|
||
|
||
Figure 1: EAP and IKEv2 endpoints are co-located
|
||
|
||
|
||
|
||
Eronen & Tschofenig Expires December 28, 2006 [Page 3]
|
||
|
||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
||
|
||
|
||
Figure 2 shows a typical corporate network access scenario. The
|
||
initiator (client) interacts with the responder (VPN gateway) in the
|
||
corporate network. The EAP exchange within IKE runs between the
|
||
client and the home AAA server. As a result of a successful EAP
|
||
authentication protocol run, session keys are established and sent
|
||
from the AAA server to the VPN gateway, and then used to authenticate
|
||
the IKEv2 SA with AUTH payloads.
|
||
|
||
The protocol used between the VPN gateway and AAA server could be,
|
||
for instance, Diameter [4] or RADIUS [5]. See Section 5 for related
|
||
security considerations.
|
||
|
||
+-------------------------------+
|
||
| Corporate network |
|
||
| |
|
||
+-----------+ +--------+ |
|
||
| IKEv2 | AAA | Home | |
|
||
IKEv2 +////----->+ Responder +<---------->+ AAA | |
|
||
Exchange / | (VPN GW) | (RADIUS/ | Server | |
|
||
/ +-----------+ Diameter) +--------+ |
|
||
/ | carrying EAP |
|
||
| | |
|
||
| +-------------------------------+
|
||
v
|
||
+------+-----+
|
||
o | IKEv2 |
|
||
/|\ | Initiator |
|
||
/ \ | VPN client |
|
||
User +------------+
|
||
|
||
Figure 2: Corporate Network Access
|
||
|
||
|
||
3. Solution
|
||
|
||
IKEv2 specifies that when the EAP method establishes a shared secret
|
||
key, that key is used by both the initiator and responder to generate
|
||
an AUTH payload (thus authenticating the IKEv2 SA set up by messages
|
||
1 and 2).
|
||
|
||
When used together with public key responder authentication, the
|
||
responder is in effect authenticated using two different methods: the
|
||
public key signature AUTH payload in message 4, and the EAP-based
|
||
AUTH payload later.
|
||
|
||
If the initiator does not wish to use public key based responder
|
||
authentication, it includes an EAP_ONLY_AUTHENTICATION notification
|
||
payload (type TBD-BY-IANA) in message 3. The SPI size field is set
|
||
|
||
|
||
|
||
Eronen & Tschofenig Expires December 28, 2006 [Page 4]
|
||
|
||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
||
|
||
|
||
to zero, and there is no additional data associated with this
|
||
notification.
|
||
|
||
If the responder supports this notification, it omits the public key
|
||
based AUTH payload and CERT payloads from message 4.
|
||
|
||
If the responder does not support the EAP_ONLY_AUTHENTICATION
|
||
notification, it ignores the notification payload, and includes the
|
||
AUTH payload in message 4. In this case the initiator can, based on
|
||
its local policy, choose to either ignore the AUTH payload, or verify
|
||
it and any associated certificates as usual.
|
||
|
||
Both the initiator and responder MUST verify that the EAP method
|
||
actually used provided mutual authentication and established a shared
|
||
secret key. The AUTH payloads sent after EAP Success MUST use the
|
||
EAP-generated key, and MUST NOT use SK_pi or SK_pr.
|
||
|
||
An IKEv2 message exchange with this modification is shown below:
|
||
|
||
|
||
Initiator Responder
|
||
----------- -----------
|
||
HDR, SAi1, KEi, Ni,
|
||
[N(NAT_DETECTION_SOURCE_IP),
|
||
N(NAT_DETECTION_DESTINATION_IP)] -->
|
||
|
||
<-- HDR, SAr1, KEr, Nr, [CERTREQ],
|
||
[N(NAT_DETECTION_SOURCE_IP),
|
||
N(NAT_DETECTION_DESTINATION_IP)]
|
||
|
||
HDR, SK { IDi, [IDr], SAi2, TSi, TSr,
|
||
N(EAP_ONLY_AUTHENTICATION),
|
||
[CP(CFG_REQUEST)] } -->
|
||
|
||
<-- HDR, SK { IDr, EAP(Request) }
|
||
|
||
HDR, SK { EAP(Response) } -->
|
||
|
||
<-- HDR, SK { EAP(Request) }
|
||
|
||
HDR, SK { EAP(Response) } -->
|
||
|
||
<-- HDR, SK { EAP(Success) }
|
||
|
||
HDR, SK { AUTH } -->
|
||
|
||
<-- HDR, SK { AUTH, SAr2, TSi, TSr,
|
||
[CP(CFG_REPLY] }
|
||
|
||
|
||
|
||
Eronen & Tschofenig Expires December 28, 2006 [Page 5]
|
||
|
||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
||
|
||
|
||
The NAT detection and Configuration payloads are shown for
|
||
informative purposes only; they do not change how EAP authentication
|
||
works.
|
||
|
||
|
||
4. IANA considerations
|
||
|
||
This document defines a new IKEv2 Notification Payload type,
|
||
EAP_ONLY_AUTHENTICATION, described in Section 3. This payload must
|
||
be assigned a new type number from the "status types" range.
|
||
|
||
This document does not define any new namespaces to be managed by
|
||
IANA.
|
||
|
||
|
||
5. Security Considerations
|
||
|
||
Security considerations applicable to all EAP methods are discussed
|
||
in [1]. The EAP Key Management Framework [7] deals with issues that
|
||
arise when EAP is used as a part of a larger system.
|
||
|
||
5.1. Authentication of IKEv2 SA
|
||
|
||
It is important to note that the IKEv2 SA is not authenticated by
|
||
just running an EAP conversation: the crucial step is the AUTH
|
||
payload based on the EAP-generated key. Thus, EAP methods that do
|
||
not provide mutual authentication or establish a shared secret key
|
||
MUST NOT be used with the modifications presented in this document.
|
||
|
||
5.2. Authentication with separated IKEv2 responder/EAP server
|
||
|
||
As described in Section 2, the EAP conversation can terminate either
|
||
at the IKEv2 responder or at a backend AAA server.
|
||
|
||
If the EAP method terminates at the IKEv2 responder then no key
|
||
transport via the AAA infrastructure is required. Pre-shared secret
|
||
and public key based authentication offered by IKEv2 is then replaced
|
||
by a wider range of authentication and key exchange methods.
|
||
|
||
However, typically EAP will be used with a backend AAA server. See
|
||
[7] for a more complete discussion of the related security issues;
|
||
here we provide only a short summary.
|
||
|
||
When a backend server is used, there are actually two authentication
|
||
exchanges: the EAP method between the client and the AAA server, and
|
||
another authentication between the AAA server and IKEv2 gateway. The
|
||
AAA server authenticates the client using the selected EAP method,
|
||
and they establish a session key. The AAA server then sends this key
|
||
|
||
|
||
|
||
Eronen & Tschofenig Expires December 28, 2006 [Page 6]
|
||
|
||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
||
|
||
|
||
to the IKEv2 gateway over a connection authenticated using, e.g.,
|
||
IPsec or TLS.
|
||
|
||
Some EAP methods do not have any concept of pass-through
|
||
authenticator (e.g., NAS or IKEv2 gateway) identity, and these two
|
||
authentications remain quite independent of each other. That is,
|
||
after the client has verified the AUTH payload sent by the IKEv2
|
||
gateway, it knows that it is talking to SOME gateway trusted by the
|
||
home AAA server, but not which one. The situation is somewhat
|
||
similar if a single cryptographic hardware accelerator, containing a
|
||
single private key, would be shared between multiple IKEv2 gateways
|
||
(perhaps in some kind of cluster configuration). In particular, if
|
||
one of the gateways is compromised, it can impersonate any of the
|
||
other gateways towards the user (until the compromise is discovered
|
||
and access rights revoked).
|
||
|
||
In some environments it is not desirable to trust the IKEv2 gateways
|
||
this much (also known as the "Lying NAS Problem"). EAP methods that
|
||
provide what is called "connection binding" or "channel binding"
|
||
transport some identity or identities of the gateway (or WLAN access
|
||
point/NAS) inside the EAP method. Then the AAA server can check that
|
||
it is indeed sending the key to the gateway expected by the client.
|
||
A potential solution is described in [16].
|
||
|
||
In some deployment configurations, AAA proxies may be present between
|
||
the IKEv2 gateway and the backend AAA server. These AAA proxies MUST
|
||
be trusted for secure operation, and therefore SHOULD be avoided when
|
||
possible; see [4] and [7] for more discussion.
|
||
|
||
5.3. Protection of EAP payloads
|
||
|
||
Although the EAP payloads are encrypted and integrity protected with
|
||
SK_e/SK_a, this does not provide any protection against active
|
||
attackers. Until the AUTH payload has been received and verified, a
|
||
man-in-the-middle can change the KEi/KEr payloads and eavesdrop or
|
||
modify the EAP payloads.
|
||
|
||
In IEEE 802.11i WLANs, the EAP payloads are neither encrypted nor
|
||
integrity protected (by the link layer), so EAP methods are typically
|
||
designed to take that into account.
|
||
|
||
In particular, EAP methods that are vulnerable to dictionary attacks
|
||
when used in WLANs are still vulnerable (to active attackers) when
|
||
run inside IKEv2.
|
||
|
||
5.4. User identity confidentiality
|
||
|
||
IKEv2 provides confidentiality for the initiator identity against
|
||
|
||
|
||
|
||
Eronen & Tschofenig Expires December 28, 2006 [Page 7]
|
||
|
||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
||
|
||
|
||
passive eavesdroppers, but not against active attackers. The
|
||
initiator announces its identity first (in message #3), before the
|
||
responder has been authenticated. The usage of EAP in IKEv2 does not
|
||
change this situation, since the ID payload in message #3 is used
|
||
instead of the EAP Identity Request/Response exchange. This is
|
||
somewhat unfortunate since when EAP is used with public key
|
||
authentication of the responder, it would be possible to provide
|
||
active user identity confidentiality for the initiator.
|
||
|
||
IKEv2 protects the responder identity even against active attacks.
|
||
This property cannot be provided when using EAP. If public key
|
||
responder authentication is used in addition to EAP, the responder
|
||
reveals its identity before authenticating the initiator. If only
|
||
EAP is used (as proposed in this document), the situation depends on
|
||
the EAP method used (in some EAP methods, the server reveals its
|
||
identity first).
|
||
|
||
Hence, if active user identity confidentiality for the initiator is
|
||
required then EAP methods that offer this functionality have to be
|
||
used (see [1], Section 7.3).
|
||
|
||
|
||
6. Acknowledgments
|
||
|
||
This document borrows some text from [1], [3], and [4]. We would
|
||
also like to thank Hugo Krawczyk for interesting discussions about
|
||
this topic.
|
||
|
||
|
||
7. References
|
||
|
||
7.1. Normative References
|
||
|
||
[1] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
|
||
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748,
|
||
June 2004.
|
||
|
||
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
|
||
Levels", RFC 2119, March 1997.
|
||
|
||
[3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
|
||
December 2005.
|
||
|
||
[4] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
|
||
Authentication Protocol (EAP) Application", RFC 4072,
|
||
August 2005.
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Tschofenig Expires December 28, 2006 [Page 8]
|
||
|
||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
||
|
||
|
||
7.2. Informative References
|
||
|
||
[5] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
|
||
In User Service) Support For Extensible Authentication Protocol
|
||
(EAP)", RFC 3579, September 2003.
|
||
|
||
[6] Aboba, B. and D. Simon, "EAP GSS Authentication Protocol",
|
||
draft-aboba-pppext-eapgss-12 (work in progress), April 2002.
|
||
|
||
[7] Aboba, B., "Extensible Authentication Protocol (EAP) Key
|
||
Management Framework", draft-ietf-eap-keying-13 (work in
|
||
progress), May 2006.
|
||
|
||
[8] Forsberg, D., "Protocol for Carrying Authentication for Network
|
||
Access (PANA)", draft-ietf-pana-pana-11 (work in progress),
|
||
March 2006.
|
||
|
||
[9] Institute of Electrical and Electronics Engineers, "Local and
|
||
Metropolitan Area Networks: Port-Based Network Access Control",
|
||
IEEE Standard 802.1X-2001, 2001.
|
||
|
||
[10] Institute of Electrical and Electronics Engineers, "Information
|
||
technology - Telecommunications and information exchange
|
||
between systems - Local and metropolitan area networks -
|
||
Specific Requirements Part 11: Wireless LAN Medium Access
|
||
Control (MAC) and Physical Layer (PHY) Specifications", IEEE
|
||
Standard 802.11-1999, 1999.
|
||
|
||
[11] Institute of Electrical and Electronics Engineers, "IEEE
|
||
Standard for Information technology - Telecommunications and
|
||
information exchange between systems - Local and metropolitan
|
||
area networks - Specific requirements - Part 11: Wireless
|
||
Medium Access Control (MAC) and Physical Layer (PHY)
|
||
specifications: Amendment 6: Medium Access Control (MAC)
|
||
Security Enhancements", IEEE Standard 802.11i-2004, July 2004.
|
||
|
||
[12] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
|
||
Authentication Dial In User Service (RADIUS)", RFC 2865,
|
||
June 2000.
|
||
|
||
[13] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
|
||
RFC 1661, July 1994.
|
||
|
||
[14] Sakane, S., Kamada, K., Thomas, M., and J. Vilhuber,
|
||
"Kerberized Internet Negotiation of Keys (KINK)", RFC 4430,
|
||
March 2006.
|
||
|
||
[15] Tschofenig, H., "EAP IKEv2 Method",
|
||
|
||
|
||
|
||
Eronen & Tschofenig Expires December 28, 2006 [Page 9]
|
||
|
||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
||
|
||
|
||
draft-tschofenig-eap-ikev2-11 (work in progress), June 2006.
|
||
|
||
[16] Arkko, J. and P. Eronen, "Authenticated Service Information for
|
||
the Extensible Authentication Protocol (EAP)",
|
||
draft-arkko-eap-service-identity-auth-04 (work in progress),
|
||
October 2005.
|
||
|
||
|
||
Appendix A. Alternative Approaches
|
||
|
||
In this section we list alternatives which have been considered
|
||
during the work on this document. Finally, the solution presented in
|
||
Section 3 seems to fit better into IKEv2.
|
||
|
||
A.1. Ignore AUTH payload at the initiator
|
||
|
||
With this approach, the initiator simply ignores the AUTH payload in
|
||
message #4 (but obviously must check the second AUTH payload later!).
|
||
The main advantage of this approach is that no protocol modifications
|
||
are required and no signature verification is required.
|
||
|
||
The initiator could signal the responder (using a NOTIFY payload)
|
||
that it did not verify the first AUTH payload.
|
||
|
||
A.2. Unauthenticated PKs in AUTH payload (message 4)
|
||
|
||
The first solution approach suggests the use of unauthenticated
|
||
public keys in the public key signature AUTH payload (for message 4).
|
||
|
||
That is, the initiator verifies the signature in the AUTH payload,
|
||
but does not verify that the public key indeed belongs to the
|
||
intended party (using certificates)--since it doesn't have a PKI that
|
||
would allow this. This could be used with X.509 certificates (the
|
||
initiator ignores all other fields of the certificate except the
|
||
public key), or "Raw RSA Key" CERT payloads.
|
||
|
||
This approach has the advantage that initiators that wish to perform
|
||
certificate-based responder authentication (in addition to EAP) may
|
||
do so, without requiring the responder to handle these cases
|
||
separately.
|
||
|
||
If using RSA, the overhead of signature verification is quite small
|
||
(compared to g^xy calculation).
|
||
|
||
A.3. Use EAP derived session keys for IKEv2
|
||
|
||
It has been proposed that when using an EAP methods that provides
|
||
mutual authentication and key agreement, the IKEv2 Diffie-Hellman
|
||
|
||
|
||
|
||
Eronen & Tschofenig Expires December 28, 2006 [Page 10]
|
||
|
||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
||
|
||
|
||
exchange could also be omitted. This would mean that the sessions
|
||
keys for IPsec SAs established later would rely only on EAP-provided
|
||
keys.
|
||
|
||
It seems the only benefit of this approach is saving some computation
|
||
time (g^xy calculation). This approach requires designing a
|
||
completely new protocol (which would not resemble IKEv2 anymore) we
|
||
do not believe that it should be considered. Nevertheless, we
|
||
include it for completeness.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Tschofenig Expires December 28, 2006 [Page 11]
|
||
|
||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
||
|
||
|
||
Authors' Addresses
|
||
|
||
Pasi Eronen
|
||
Nokia Research Center
|
||
P.O. Box 407
|
||
FIN-00045 Nokia Group
|
||
Finland
|
||
|
||
Email: pasi.eronen@nokia.com
|
||
|
||
|
||
Hannes Tschofenig
|
||
Siemens
|
||
Otto-Hahn-Ring 6
|
||
Munich, Bayern 81739
|
||
Germany
|
||
|
||
Email: Hannes.Tschofenig@siemens.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Tschofenig Expires December 28, 2006 [Page 12]
|
||
|
||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
||
|
||
|
||
Intellectual Property Statement
|
||
|
||
The IETF takes no position regarding the validity or scope of any
|
||
Intellectual Property Rights or other rights that might be claimed to
|
||
pertain to the implementation or use of the technology described in
|
||
this document or the extent to which any license under such rights
|
||
might or might not be available; nor does it represent that it has
|
||
made any independent effort to identify any such rights. Information
|
||
on the procedures with respect to rights in RFC documents can be
|
||
found in BCP 78 and BCP 79.
|
||
|
||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||
assurances of licenses to be made available, or the result of an
|
||
attempt made to obtain a general license or permission for the use of
|
||
such proprietary rights by implementers or users of this
|
||
specification can be obtained from the IETF on-line IPR repository at
|
||
http://www.ietf.org/ipr.
|
||
|
||
The IETF invites any interested party to bring to its attention any
|
||
copyrights, patents or patent applications, or other proprietary
|
||
rights that may cover technology that may be required to implement
|
||
this standard. Please address the information to the IETF at
|
||
ietf-ipr@ietf.org.
|
||
|
||
|
||
Disclaimer of Validity
|
||
|
||
This document and the information contained herein are provided on an
|
||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
|
||
Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (2006). This document is subject
|
||
to the rights, licenses and restrictions contained in BCP 78, and
|
||
except as set forth therein, the authors retain all their rights.
|
||
|
||
|
||
Acknowledgment
|
||
|
||
Funding for the RFC Editor function is currently provided by the
|
||
Internet Society.
|
||
|
||
|
||
|
||
|
||
Eronen & Tschofenig Expires December 28, 2006 [Page 13]
|
||
|
||
|