merged EAP framework from branch into trunk

includes a lot of other modifications
This commit is contained in:
Martin Willi 2007-02-12 15:56:47 +00:00
parent 6fda18d99d
commit f27f6296e6
64 changed files with 8539 additions and 482 deletions

View File

@ -19,9 +19,7 @@ dnl ===========================
AC_INIT(strongSwan,4.0.8)
AM_INIT_AUTOMAKE(tar-ustar)
AC_C_BIGENDIAN
AC_SUBST(ipsecdir, '${libexecdir}/ipsec')
AC_SUBST(confdir, '${sysconfdir}')
AC_SUBST(piddir, '/var/run')
dnl =================================
dnl check --enable-xxx & --with-xxx
@ -30,7 +28,7 @@ dnl =================================
AC_ARG_WITH(
[default-pkcs11],
AS_HELP_STRING([--with-default-pkcs11=lib],[set the default PKCS11 library other than /usr/lib/opensc-pkcs11.so]),
AS_HELP_STRING([--with-default-pkcs11=lib],[set the default PKCS11 library other than "/usr/lib/opensc-pkcs11.so"]),
[AC_DEFINE_UNQUOTED(PKCS11_DEFAULT_LIB, "$withval")],
[AC_DEFINE_UNQUOTED(PKCS11_DEFAULT_LIB, "/usr/lib/opensc-pkcs11.so")]
)
@ -43,18 +41,39 @@ AC_ARG_WITH(
AC_ARG_WITH(
[random-device],
AS_HELP_STRING([--with-random-device=dev],[set the device for real random data other than /dev/random]),
AS_HELP_STRING([--with-random-device=dev],[set the device for real random data other than "/dev/random"]),
[AC_DEFINE_UNQUOTED(DEV_RANDOM, "$withval")],
[AC_DEFINE_UNQUOTED(DEV_RANDOM, "/dev/random")]
)
AC_ARG_WITH(
[urandom-device],
AS_HELP_STRING([--with-urandom-device=dev],[set the device for pseudo random data other than /dev/urandom]),
AS_HELP_STRING([--with-urandom-device=dev],[set the device for pseudo random data other than "/dev/urandom"]),
[AC_DEFINE_UNQUOTED(DEV_URANDOM, "$withval")],
[AC_DEFINE_UNQUOTED(DEV_URANDOM, "/dev/urandom")]
)
AC_ARG_WITH(
[ipsecdir],
AS_HELP_STRING([--with-ipsecdir=dir],[installation path for ipsec tools other than "libexecdir/ipsec"]),
[AC_SUBST(ipsecdir, "$withval")],
[AC_SUBST(ipsecdir, "${libexecdir}/ipsec")]
)
AC_ARG_WITH(
[piddir],
AS_HELP_STRING([--with-piddir=dir],[path for PID and UNIX socket files other than "/var/run"]),
[AC_SUBST(piddir, "$withval")],
[AC_SUBST(piddir, "/var/run")]
)
AC_ARG_WITH(
[eapdir],
AS_HELP_STRING([--with-eapdir=dir],[path for pluggable EAP modules other than "ipsecdir/eap"]),
[AC_SUBST(eapdir, "$withval")],
[AC_SUBST(eapdir, "${ipsecdir}/eap")]
)
AC_ARG_ENABLE(
[http],
AS_HELP_STRING([--enable-http],[enable OCSP and fetching of Certificates and CRLs over HTTP (default is NO). Requires libcurl.]),

View File

@ -1,2 +1,4 @@
#!/bin/bash
CFLAGS="-Wall -Wno-format -Wno-pointer-sign -Wno-strict-aliasing -g -O2" ./configure --sysconfdir=/etc --with-random-device=/dev/urandom --enable-ldap --enable-http --enable-leak-detective
CFLAGS="-Wall -Wno-format -Wno-pointer-sign -Wno-strict-aliasing -g -O2" ./configure \
--sysconfdir=/etc --with-random-device=/dev/urandom --enable-ldap --enable-http \
--enable-leak-detective

View File

@ -1,2 +1,3 @@
#!/bin/bash
CFLAGS="-Wall -Wno-format -Wno-pointer-sign -Wno-strict-aliasing -O2 -DDEBUG_LEVEL=0" ./configure --sysconfdir=/etc --with-random-device=/dev/urandom --enable-ldap --enable-http
CFLAGS="-Wall -Wno-format -Wno-pointer-sign -Wno-strict-aliasing -O2 -DDEBUG_LEVEL=0" ./configure \
--sysconfdir=/etc --with-random-device=/dev/urandom --enable-ldap --enable-http

View File

@ -1,2 +1,3 @@
#!/bin/bash
CFLAGS="-Wall -Wno-format -Wno-pointer-sign -Wno-strict-aliasing -g -O2" ./configure --sysconfdir=/etc --with-random-device=/dev/urandom --enable-ldap --enable-http
CFLAGS="-Wall -Wno-format -Wno-pointer-sign -Wno-strict-aliasing -g -O2" ./configure \
--sysconfdir=/etc --with-random-device=/dev/urandom --enable-ldap --enable-http

View File

@ -1,5 +1,9 @@
# SUBDIRS = . testing
eap_LTLIBRARIES =
# build optional EAP modules
ipsec_PROGRAMS = charon
charon_SOURCES = \
@ -24,6 +28,8 @@ sa/transactions/rekey_ike_sa.h sa/transactions/rekey_ike_sa.c \
sa/authenticators/authenticator.h sa/authenticators/authenticator.c \
sa/authenticators/rsa_authenticator.h sa/authenticators/rsa_authenticator.c \
sa/authenticators/psk_authenticator.h sa/authenticators/psk_authenticator.c \
sa/authenticators/eap_authenticator.h sa/authenticators/eap_authenticator.c \
sa/authenticators/eap/eap_method.h sa/authenticators/eap/eap_method.c \
sa/child_sa.c sa/child_sa.h sa/ike_sa.c sa/ike_sa.h sa/ike_sa_manager.c sa/ike_sa_manager.h \
sa/ike_sa_id.c sa/ike_sa_id.h encoding/payloads/encryption_payload.c \
encoding/payloads/cert_payload.c encoding/payloads/payload.h encoding/payloads/traffic_selector_substructure.c \
@ -59,5 +65,5 @@ threads/sender.h threads/kernel_interface.h threads/scheduler.h threads/receiver
threads/thread_pool.h threads/receiver.h threads/stroke_interface.h
INCLUDES = -I$(top_srcdir)/src/libstrongswan -I$(top_srcdir)/src/charon -I$(top_srcdir)/src/stroke
AM_CFLAGS = -DIPSEC_CONFDIR=\"${confdir}\" -DIPSEC_PIDDIR=\"${piddir}\"
charon_LDADD = $(top_builddir)/src/libstrongswan/libstrongswan.la -lgmp -lpthread -lm
AM_CFLAGS = -rdynamic -DIPSEC_CONFDIR=\"${confdir}\" -DIPSEC_PIDDIR=\"${piddir}\" -DIPSEC_EAPDIR=\"${eapdir}\"
charon_LDADD = $(top_builddir)/src/libstrongswan/libstrongswan.la -lgmp -lpthread -lm -ldl

View File

@ -92,8 +92,7 @@ static bool contains_traffic_selectors(policy_t *policy, bool mine,
static policy_t *get_policy(private_local_policy_store_t *this,
identification_t *my_id, identification_t *other_id,
linked_list_t *my_ts, linked_list_t *other_ts,
host_t *my_host, host_t *other_host,
linked_list_t *requested_ca_keyids)
host_t *my_host, host_t *other_host)
{
typedef enum {
PRIO_UNDEFINED = 0x00,
@ -254,7 +253,7 @@ local_policy_store_t *local_policy_store_create(void)
this->public.policy_store.add_policy = (void (*) (policy_store_t*,policy_t*))add_policy;
this->public.policy_store.get_policy = (policy_t* (*) (policy_store_t*,identification_t*,identification_t*,
linked_list_t*,linked_list_t*,host_t*,host_t*,linked_list_t*))get_policy;
linked_list_t*,linked_list_t*,host_t*,host_t*))get_policy;
this->public.policy_store.get_policy_by_name = (policy_t* (*) (policy_store_t*,char*))get_policy_by_name;
this->public.policy_store.delete_policy = (status_t (*) (policy_store_t*,char*))delete_policy;
this->public.policy_store.create_iterator = (iterator_t* (*) (policy_store_t*))create_iterator;

View File

@ -83,6 +83,11 @@ struct private_policy_t {
*/
auth_method_t auth_method;
/**
* EAP type to use for peer authentication
*/
eap_type_t eap_type;
/**
* we have a cert issued by this CA
*/
@ -193,6 +198,14 @@ static auth_method_t get_auth_method(private_policy_t *this)
return this->auth_method;
}
/**
* Implementation of connection_t.get_eap_type.
*/
static eap_type_t get_eap_type(private_policy_t *this)
{
return this->eap_type;
}
/**
* Get traffic selectors, with wildcard-address update
*/
@ -492,7 +505,7 @@ static void destroy(private_policy_t *this)
* Described in header-file
*/
policy_t *policy_create(char *name, identification_t *my_id, identification_t *other_id,
auth_method_t auth_method,
auth_method_t auth_method, eap_type_t eap_type,
u_int32_t hard_lifetime, u_int32_t soft_lifetime,
u_int32_t jitter, char *updown, bool hostaccess,
mode_t mode, dpd_action_t dpd_action)
@ -506,6 +519,7 @@ policy_t *policy_create(char *name, identification_t *my_id, identification_t *o
this->public.get_my_ca = (identification_t* (*) (policy_t*))get_my_ca;
this->public.get_other_ca = (identification_t* (*) (policy_t*))get_other_ca;
this->public.get_auth_method = (auth_method_t (*) (policy_t*)) get_auth_method;
this->public.get_eap_type = (eap_type_t (*) (policy_t*)) get_eap_type;
this->public.get_my_traffic_selectors = (linked_list_t* (*) (policy_t*,host_t*))get_my_traffic_selectors;
this->public.get_other_traffic_selectors = (linked_list_t* (*) (policy_t*,host_t*))get_other_traffic_selectors;
this->public.select_my_traffic_selectors = (linked_list_t* (*) (policy_t*,linked_list_t*,host_t*))select_my_traffic_selectors;
@ -530,6 +544,7 @@ policy_t *policy_create(char *name, identification_t *my_id, identification_t *o
this->my_id = my_id;
this->other_id = other_id;
this->auth_method = auth_method;
this->eap_type = eap_type;
this->hard_lifetime = hard_lifetime;
this->soft_lifetime = soft_lifetime;
this->jitter = jitter;

View File

@ -32,6 +32,7 @@ typedef struct policy_t policy_t;
#include <config/traffic_selector.h>
#include <config/proposal.h>
#include <sa/authenticators/authenticator.h>
#include <sa/authenticators/eap/eap_method.h>
/**
@ -148,6 +149,14 @@ struct policy_t {
* @return authentication method
*/
auth_method_t (*get_auth_method) (policy_t *this);
/**
* @brief Get the EAP type to use for peer authentication.
*
* @param this calling object
* @return authentication method
*/
eap_type_t (*get_eap_type) (policy_t *this);
/**
* @brief Get configured traffic selectors for our site.
@ -358,6 +367,7 @@ struct policy_t {
* @param my_id identification_t for ourselves
* @param other_id identification_t for the remote guy
* @param auth_method Authentication method to use for our(!) auth data
* @param eap_type EAP type to use for peer authentication
* @param hard_lifetime lifetime before deleting an SA
* @param soft_lifetime lifetime before rekeying an SA
* @param jitter range of randomization time
@ -371,7 +381,7 @@ struct policy_t {
*/
policy_t *policy_create(char *name,
identification_t *my_id, identification_t *other_id,
auth_method_t auth_method,
auth_method_t auth_method, eap_type_t eap_type,
u_int32_t hard_lifetime, u_int32_t soft_lifetime,
u_int32_t jitter, char *updown, bool hostaccess,
mode_t mode, dpd_action_t dpd_action);

View File

@ -49,14 +49,13 @@ struct policy_store_t {
* other_id must be fully qualified. my_id may be %any, as the
* other peer may not include an IDr Request.
*
* @param this calling object
* @param my_id own ID of the policy
* @param other_id others ID of the policy
* @param my_ts traffic selectors requested for local host
* @param other_ts traffic selectors requested for remote host
* @param my_host host to use for wilcards in TS compare
* @param other_host host to use for wildcards in TS compare
* @param requested_ca_keyids list of requested CA keyids
* @param this calling object
* @param my_id own ID of the policy
* @param other_id others ID of the policy
* @param my_ts traffic selectors requested for local host
* @param other_ts traffic selectors requested for remote host
* @param my_host host to use for wilcards in TS compare
* @param other_host host to use for wildcards in TS compare
* @return
* - matching policy_t, if found
* - NULL otherwise
@ -64,8 +63,7 @@ struct policy_store_t {
policy_t *(*get_policy) (policy_store_t *this,
identification_t *my_id, identification_t *other_id,
linked_list_t *my_ts, linked_list_t *other_ts,
host_t *my_host, host_t* other_host,
linked_list_t *requested_ca_keyids);
host_t *my_host, host_t* other_host);
/**
* @brief Returns a policy identified by a connection name.

View File

@ -42,6 +42,7 @@
#include <config/credentials/local_credential_store.h>
#include <config/connections/local_connection_store.h>
#include <config/policies/local_policy_store.h>
#include <sa/authenticators/eap/eap_method.h>
typedef struct private_daemon_t private_daemon_t;
@ -393,6 +394,7 @@ int main(int argc, char *argv[])
{
bool strict_crl_policy = FALSE;
bool use_syslog = FALSE;
char *eapdir = IPSEC_EAPDIR;
private_daemon_t *private_charon;
FILE *pid_file;
@ -416,6 +418,7 @@ int main(int argc, char *argv[])
{ "version", no_argument, NULL, 'v' },
{ "use-syslog", no_argument, NULL, 'l' },
{ "strictcrlpolicy", no_argument, NULL, 'r' },
{ "eapdir", required_argument, NULL, 'e' },
/* TODO: handle "debug-all" */
{ "debug-dmn", required_argument, &signal, DBG_DMN },
{ "debug-mgr", required_argument, &signal, DBG_MGR },
@ -447,6 +450,9 @@ int main(int argc, char *argv[])
case 'r':
strict_crl_policy = TRUE;
continue;
case 'e':
eapdir = optarg;
continue;
case 0:
/* option is in signal */
levels[signal] = atoi(optarg);
@ -463,6 +469,8 @@ int main(int argc, char *argv[])
/* initialize daemon */
initialize(private_charon, strict_crl_policy, use_syslog, levels);
/* load pluggable EAP modules */
eap_method_load(eapdir);
/* check/setup PID file */
if (stat(PID_FILE, &stb) == 0)
@ -477,6 +485,7 @@ int main(int argc, char *argv[])
fprintf(pid_file, "%d\n", getpid());
fclose(pid_file);
}
/* log socket info */
list = charon->socket->create_local_address_list(charon->socket);
DBG1(DBG_NET, "listening on %d addresses:", list->get_count(list));
@ -490,6 +499,7 @@ int main(int argc, char *argv[])
/* run daemon */
run(private_charon);
eap_method_unload();
/* normal termination, cleanup and exit */
destroy(private_charon);
unlink(PID_FILE);

View File

@ -179,6 +179,14 @@ typedef struct daemon_t daemon_t;
* @ingroup sa
*/
/**
* @defgroup eap eap
*
* EAP authentication module interface and it's implementations.
*
* @ingroup authenticators
*/
/**
* @defgroup threads threads
*

File diff suppressed because it is too large Load Diff

View File

@ -0,0 +1,619 @@
Network Working Group P. Eronen
Request for Comments: 4739 Nokia
Category: Experimental J. Korhonen
TeliaSonera
November 2006
Multiple Authentication Exchanges
in the Internet Key Exchange (IKEv2) Protocol
Status of This Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2006).
Abstract
The Internet Key Exchange (IKEv2) protocol supports several
mechanisms for authenticating the parties, including signatures with
public-key certificates, shared secrets, and Extensible
Authentication Protocol (EAP) methods. Currently, each endpoint uses
only one of these mechanisms to authenticate itself. This document
specifies an extension to IKEv2 that allows the use of multiple
authentication exchanges, using either different mechanisms or the
same mechanism. This extension allows, for instance, performing
certificate-based authentication of the client host followed by an
EAP authentication of the user. When backend authentication servers
are used, they can belong to different administrative domains, such
as the network access provider and the service provider.
Eronen & Korhonen Experimental [Page 1]
RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006
Table of Contents
1. Introduction ....................................................3
1.1. Usage Scenarios ............................................4
1.2. Terminology ................................................5
2. Solution ........................................................5
2.1. Solution Overview ..........................................5
2.2. Example 1: Multiple EAP Authentications ....................6
2.3. Example 2: Mixed EAP and Certificate Authentications .......7
2.4. Example 3: Multiple Initiator Certificates .................8
2.5. Example 4: Multiple Responder Certificates .................8
3. Payload Formats .................................................9
3.1. MULTIPLE_AUTH_SUPPORTED Notify Payload .....................9
3.2. ANOTHER_AUTH_FOLLOWS Notify Payload ........................9
4. IANA Considerations .............................................9
5. Security Considerations .........................................9
6. Acknowledgments ................................................10
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................10
Eronen & Korhonen Experimental [Page 2]
RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006
1. Introduction
IKEv2 [IKEv2] supports several mechanisms for parties involved in the
IKE_SA (IKE security association). These include signatures with
public-key certificates, shared secrets, and Extensible
Authentication Protocol (EAP) methods.
Currently, each endpoint uses only one of these mechanisms to
authenticate itself. However, there are scenarios where making the
authorization decision in IKEv2 (whether to allow access or not)
requires using several of these methods.
For instance, it may be necessary to authenticate both the host
(machine) requesting access, and the user currently using the host.
These two authentications would use two separate sets of credentials
(such as certificates and associated private keys) and might even use
different authentication mechanisms.
To take another example, when an operator is hosting a Virtual
Private Network (VPN) gateway service for a third party, it may be
necessary to authenticate the client to both the operator (for
billing purposes) and the third party's Authentication,
Authorization, and Accounting (AAA) server (for authorizing access to
the third party's internal network).
This document specifies an extension to IKEv2 that allows the use of
multiple authentication exchanges, using either different mechanisms
or the same mechanism. This extension allows, for instance,
performing certificate-based authentication of the client host
followed by an EAP authentication of the user.
Each authentication exchange requiring communication with backend AAA
servers may be directed to different backend AAA servers, located
even in different administrative domains. However, details of the
communication between the IKEv2 gateway and the backend
authentication servers are beyond the scope of this document. In
particular, this document does not specify any changes to existing
AAA protocols, and it does not require the use of any particular AAA
protocol.
In case of several EAP authentications, it is important to notice
that they are not a "sequence" (as described in Section 2.1 of
[EAP]), but separate independent EAP conversations, which are usually
also terminated in different EAP servers. Multiple authentication
methods within a single EAP conversation are still prohibited as
described in Section 2.1 of [EAP]. Using multiple independent EAP
conversations is similar to the separate Network Access Provider
(NAP) and Internet Service Provider (ISP) authentication exchanges
Eronen & Korhonen Experimental [Page 3]
RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006
planned for [PANA]. The discovery of the appropriate EAP server for
each EAP authentication conversation is based on AAA routing.
1.1. Usage Scenarios
Figure 1 shows an example architecture of an operator-hosted VPN
scenario that could benefit from a two-phase authentication within
the IKEv2 exchange. First, the client authenticates towards the
Network Access Provider (NAP) and gets access to the NAP-hosted VPN
gateway. The first-phase authentication involves the backend AAA
server of the NAP. After the first authentication, the client
initiates the second authentication round that also involves the
Third Party's backend AAA server. If both authentications succeed,
the required IPsec tunnels are set up and the client can access
protected networks behind the Third Party.
Client *Network Access Provider*
+---------+ +---------+ +-----+
| | | NAP's | | NAP |
|Protected| IPsec SAs | Tunnel | AAA Protocol | AAA |
|Endpoint |<------------------>|Endpoint |<------------>|Serv/|
| | | | |Proxy|
+---------+ +---------+ +-----+
^ ^
IPsec or / AAA |
Leased Line / Protocol |
/ |
v |
+---------+ *Third Party* v
|3rd Party| +-----+
Protected | Tunnel | | 3rd |
Subnet <----|Endpoint | |Party|
| | | AAA |
+---------+ +-----+
Figure 1: Two-phase authentication used to gain access to
the Third Party network via Network Access Provider. AAA
traffic goes through NAP's AAA server.
The NAP's AAA server can be used to proxy the AAA traffic to the
Third Party's backend AAA server. Alternatively, the AAA traffic
from the NAP's tunnel endpoint could go directly to the Third Party's
backend AAA servers. However, this is more or less an AAA routing
issue.
Eronen & Korhonen Experimental [Page 4]
RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006
1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS].
The terms and abbreviations "authenticator", "backend authentication
server", "EAP server", and "peer" in this document are to be
interpreted as described in [EAP].
When messages containing IKEv2 payloads are described, optional
payloads are shown in brackets (for instance, "[FOO]"), and a plus
sign indicates that a payload can be repeated one or more times (for
instance, "FOO+").
2. Solution
2.1. Solution Overview
The peers announce support for this IKEv2 extension by including a
MULTIPLE_AUTH_SUPPORTED notification in the IKE_SA_INIT response
(responder) and the first IKE_AUTH request (initiator).
If both peers support this extension, either of them can announce
that it wishes to have a second authentication by including an
ANOTHER_AUTH_FOLLOWS notification in any IKE_AUTH message that
contains an AUTH payload. This indicates that the peer sending the
ANOTHER_AUTH_FOLLOWS wishes to authenticate another set of
credentials to the other peer. The next IKE_AUTH message sent by
this peer will contain a second identity payload (IDi or IDr) and
starts another authentication exchange. The IKE_AUTH phase is
considered successful only if all the individual authentication
exchanges complete successfully.
It is assumed that both peers know what credentials they want to
present; there is no negotiation about, for instance, what type of
authentication is to be done. As in IKEv2, EAP-based authentication
is always requested by the initiator (by omitting the AUTH payload).
The AUTH payloads are calculated as specified in [IKEv2] Sections
2.15 and 2.16, where IDi' refers to the latest IDi payload sent by
the initiator, and IDr' refers to the latest IDr payload sent by the
responder. If EAP methods that do not generate shared keys are used,
it is possible that several AUTH payloads with identical contents are
sent. When such EAP methods are used, the purpose of the AUTH
payload is simply to delimit the authentication exchanges, and ensure
that the IKE_SA_INIT request/response messages were not modified.
Eronen & Korhonen Experimental [Page 5]
RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006
2.2. Example 1: Multiple EAP Authentications
This example shows certificate-based authentication of the responder
followed by an EAP authentication exchange (messages 1-10). When the
first EAP exchange is ending (the initiator is sending its AUTH
payload), the initiator announces that it wishes to have a second
authentication exchange by including an ANOTHER_AUTH_FOLLOWS
notification (message 9).
After this, a second authentication exchange begins. The initiator
sends a new IDi payload but no AUTH payload (message 11), indicating
that EAP will be used. After that, another EAP authentication
exchange follows (messages 12-18).
Initiator Responder
----------- -----------
1. HDR, SA, KE, Ni -->
<-- 2. HDR, SA, KE, Nr, [CERTREQ],
N(MULTIPLE_AUTH_SUPPORTED)
3. HDR, SK { IDi, [CERTREQ+], [IDr],
SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED) } -->
<-- 4. HDR, SK { IDr, [CERT+], AUTH,
EAP(Request) }
5. HDR, SK { EAP(Response) } -->
<-- 6. HDR, SK { EAP(Request) }
7. HDR, SK { EAP(Response) } -->
<-- 8. HDR, SK { EAP(Success) }
9. HDR, SK { AUTH,
N(ANOTHER_AUTH_FOLLOWS) } -->
<-- 10. HDR, SK { AUTH }
11. HDR, SK { IDi } -->
<-- 12. HDR, SK { EAP(Request) }
13. HDR, SK { EAP(Response) } -->
<-- 14. HDR, SK { EAP(Request) }
15. HDR, SK { EAP(Response) } -->
<-- 16. HDR, SK { EAP(Success) }
17. HDR, SK { AUTH } -->
<-- 18. HDR, SK { AUTH, SA, TSi, TSr }
Example 1: Certificate-based authentication of the
responder, followed by two EAP authentication exchanges.
Eronen & Korhonen Experimental [Page 6]
RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006
2.3. Example 2: Mixed EAP and Certificate Authentications
Another example is shown below: here both the initiator and the
responder are first authenticated using certificates (or shared
secrets); this is followed by an EAP authentication exchange.
Initiator Responder
----------- -----------
1. HDR, SA, KE, Ni -->
<-- 2. HDR, SA, KE, Nr, [CERTREQ],
N(MULTIPLE_AUTH_SUPPORTED)
3. HDR, SK { IDi, [CERT+], [CERTREQ+], [IDr], AUTH,
SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED),
N(ANOTHER_AUTH_FOLLOWS) } -->
<-- 4. HDR, SK { IDr, [CERT+], AUTH }
5. HDR, SK { IDi } -->
<-- 6. HDR, SK { EAP(Request) }
7. HDR, SK { EAP(Response) } -->
<-- 8. HDR, SK { EAP(Request) }
9. HDR, SK { EAP(Response) } -->
<-- 10. HDR, SK { EAP(Success) }
11. HDR, SK { AUTH } -->
<-- 12. HDR, SK { AUTH, SA, TSi, TSr }
Example 2: Certificate-based (or shared-secret-based)
authentication of the initiator and the responder,
followed by an EAP authentication exchange.
Eronen & Korhonen Experimental [Page 7]
RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006
2.4. Example 3: Multiple Initiator Certificates
This example shows yet another possibility: the initiator has two
different certificates (and associated private keys), and
authenticates both of them to the responder.
Initiator Responder
----------- -----------
1. HDR, SA, KE, Ni -->
<-- 2. HDR, SA, KE, Nr, [CERTREQ],
N(MULTIPLE_AUTH_SUPPORTED)
3. HDR, SK { IDi, [CERT+], [CERTREQ+], [IDr], AUTH,
SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED),
N(ANOTHER_AUTH_FOLLOWS) } -->
<-- 4. HDR, SK { IDr, [CERT+], AUTH }
5. HDR, SK { IDi, [CERT+], AUTH } -->
<-- 6. HDR, SK { SA, TSi, TSr }
Example 3: Two certificate-based authentications of the
initiator, and one certificate-based authentication
of the responder.
2.5. Example 4: Multiple Responder Certificates
This example shows yet another possibility: the responder has two
different certificates (and associated private keys), and
authenticates both of them to the initiator.
Initiator Responder
----------- -----------
1. HDR, SA, KE, Ni -->
<-- 2. HDR, SA, KE, Nr, [CERTREQ],
N(MULTIPLE_AUTH_SUPPORTED)
3. HDR, SK { IDi, [CERT+], [CERTREQ+], [IDr], AUTH,
SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED) } -->
<-- 4. HDR, SK { IDr, [CERT+], AUTH,
N(ANOTHER_AUTH_FOLLOWS) }
5. HDR, SK { } -->
<-- 6. HDR, SK { IDr, [CERT+], AUTH,
SA, TSi, TSr }
Example 4: Two certificate-based authentications of the
responder, and one certificate-based authentication
of the initiator.
Eronen & Korhonen Experimental [Page 8]
RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006
3. Payload Formats
3.1. MULTIPLE_AUTH_SUPPORTED Notify Payload
The MULTIPLE_AUTH_SUPPORTED notification is included in the
IKE_SA_INIT response or the first IKE_AUTH request to indicate that
the peer supports this specification. The Notify Message Type is
MULTIPLE_AUTH_SUPPORTED (16404). The Protocol ID and SPI Size fields
MUST be set to zero, and there is no data associated with this Notify
type.
3.2. ANOTHER_AUTH_FOLLOWS Notify Payload
The ANOTHER_AUTH_FOLLOWS notification payload is included in an
IKE_AUTH message containing an AUTH payload to indicate that the peer
wants to continue with another authentication exchange. The Notify
Message Type is ANOTHER_AUTH_FOLLOWS (16405). The Protocol ID and
SPI Size fields MUST be set to zero, and there is no data associated
with this Notify type.
4. IANA Considerations
This document defines two new IKEv2 notifications,
MULTIPLE_AUTH_SUPPORTED and ANOTHER_AUTH_FOLLOWS, whose values are
allocated from the "IKEv2 Notify Message Types" namespace defined in
[IKEv2].
This document does not define any new namespaces to be managed by
IANA.
5. Security Considerations
Security considerations for IKEv2 are discussed in [IKEv2]. The
reader is encouraged to pay special attention to considerations
relating to the use of EAP methods that do not generate shared keys.
However, the use of multiple authentication exchanges results in at
least one new security consideration.
In normal IKEv2, the responder authenticates the initiator before
revealing its identity (except when EAP is used). When multiple
authentication exchanges are used to authenticate the initiator, the
responder has to reveal its identity before all of the initiator
authentication exchanges have been completed.
Eronen & Korhonen Experimental [Page 9]
RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006
6. Acknowledgments
The authors would like to thank Bernard Aboba, Jari Arkko, Spencer
Dawkins, Lakshminath Dondeti, Henry Haverinen, Russ Housley, Mika
Joutsenvirta, Charlie Kaufman, Tero Kivinen, Yoav Nir, Magnus
Nystrom, Mohan Parthasarathy, and Juha Savolainen for their valuable
comments.
7. References
7.1. Normative References
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
7.2. Informative References
[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[PANA] Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C.
Wang, "Protocol for Carrying Authentication for Network
Access (PANA) Requirements", RFC 4058, May 2005.
Authors' Addresses
Pasi Eronen
Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
Finland
EMail: pasi.eronen@nokia.com
Jouni Korhonen
TeliaSonera
P.O. Box 970
FIN-00051 Sonera
Finland
EMail: jouni.korhonen@teliasonera.com
Eronen & Korhonen Experimental [Page 10]
RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006
Full Copyright Statement
Copyright (C) The IETF Trust (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Eronen & Korhonen Experimental [Page 11]

View File

@ -738,7 +738,7 @@ static void generate_payload (private_generator_t *this,payload_t *payload)
case SPIS:
case CONFIGURATION_ATTRIBUTE_VALUE:
case VID_DATA:
case EAP_MESSAGE:
case EAP_DATA:
{
u_int32_t payload_length_position_offset;
u_int16_t length_of_payload;
@ -777,7 +777,7 @@ static void generate_payload (private_generator_t *this,payload_t *payload)
case CONFIGURATION_ATTRIBUTE_VALUE:
header_length = CONFIGURATION_ATTRIBUTE_HEADER_LENGTH;
break;
case EAP_MESSAGE:
case EAP_DATA:
header_length = EAP_PAYLOAD_HEADER_LENGTH;
break;
default:

View File

@ -142,11 +142,12 @@ static payload_rule_t ike_sa_init_r_payload_rules[] = {
*/
static payload_rule_t ike_auth_i_payload_rules[] = {
{NOTIFY,0,MAX_NOTIFY_PAYLOADS,TRUE,FALSE},
{EXTENSIBLE_AUTHENTICATION,0,1,TRUE,TRUE},
{AUTHENTICATION,0,1,TRUE,TRUE},
{ID_INITIATOR,1,1,TRUE,FALSE},
{CERTIFICATE,0,1,TRUE,FALSE},
{CERTIFICATE_REQUEST,0,1,TRUE,FALSE},
{ID_RESPONDER,0,1,TRUE,FALSE},
{AUTHENTICATION,1,1,TRUE,FALSE},
{SECURITY_ASSOCIATION,1,1,TRUE,FALSE},
{TRAFFIC_SELECTOR_INITIATOR,1,1,TRUE,FALSE},
{TRAFFIC_SELECTOR_RESPONDER,1,1,TRUE,FALSE},
@ -158,12 +159,13 @@ static payload_rule_t ike_auth_i_payload_rules[] = {
*/
static payload_rule_t ike_auth_r_payload_rules[] = {
{NOTIFY,0,MAX_NOTIFY_PAYLOADS,TRUE,TRUE},
{EXTENSIBLE_AUTHENTICATION,0,1,TRUE,TRUE},
{CERTIFICATE,0,1,TRUE,FALSE},
{ID_RESPONDER,1,1,TRUE,FALSE},
{AUTHENTICATION,1,1,TRUE,FALSE},
{SECURITY_ASSOCIATION,1,1,TRUE,FALSE},
{TRAFFIC_SELECTOR_INITIATOR,1,1,TRUE,FALSE},
{TRAFFIC_SELECTOR_RESPONDER,1,1,TRUE,FALSE},
{ID_RESPONDER,0,1,TRUE,FALSE},
{AUTHENTICATION,0,1,TRUE,FALSE},
{SECURITY_ASSOCIATION,0,1,TRUE,FALSE},
{TRAFFIC_SELECTOR_INITIATOR,0,1,TRUE,FALSE},
{TRAFFIC_SELECTOR_RESPONDER,0,1,TRUE,FALSE},
{CONFIGURATION,0,1,TRUE,FALSE},
};

View File

@ -626,7 +626,7 @@ static status_t parse_payload(private_parser_t *this, payload_type_t payload_typ
pld->destroy(pld);
return PARSE_ERROR;
}
break;
break;
}
case U_INT_32:
{
@ -635,7 +635,7 @@ static status_t parse_payload(private_parser_t *this, payload_type_t payload_typ
pld->destroy(pld);
return PARSE_ERROR;
}
break;
break;
}
case U_INT_64:
{
@ -644,7 +644,7 @@ static status_t parse_payload(private_parser_t *this, payload_type_t payload_typ
pld->destroy(pld);
return PARSE_ERROR;
}
break;
break;
}
case IKE_SPI:
{
@ -653,7 +653,7 @@ static status_t parse_payload(private_parser_t *this, payload_type_t payload_typ
pld->destroy(pld);
return PARSE_ERROR;
}
break;
break;
}
case RESERVED_BIT:
{
@ -662,7 +662,7 @@ static status_t parse_payload(private_parser_t *this, payload_type_t payload_typ
pld->destroy(pld);
return PARSE_ERROR;
}
break;
break;
}
case RESERVED_BYTE:
{
@ -680,7 +680,7 @@ static status_t parse_payload(private_parser_t *this, payload_type_t payload_typ
pld->destroy(pld);
return PARSE_ERROR;
}
break;
break;
}
case PAYLOAD_LENGTH:
{
@ -690,7 +690,7 @@ static status_t parse_payload(private_parser_t *this, payload_type_t payload_typ
return PARSE_ERROR;
}
payload_length = *(u_int16_t*)(output + rule->offset);
break;
break;
}
case HEADER_LENGTH:
{
@ -699,7 +699,7 @@ static status_t parse_payload(private_parser_t *this, payload_type_t payload_typ
pld->destroy(pld);
return PARSE_ERROR;
}
break;
break;
}
case SPI_SIZE:
{
@ -709,7 +709,7 @@ static status_t parse_payload(private_parser_t *this, payload_type_t payload_typ
return PARSE_ERROR;
}
spi_size = *(u_int8_t*)(output + rule->offset);
break;
break;
}
case SPI:
{
@ -718,7 +718,7 @@ static status_t parse_payload(private_parser_t *this, payload_type_t payload_typ
pld->destroy(pld);
return PARSE_ERROR;
}
break;
break;
}
case PROPOSALS:
{
@ -728,7 +728,7 @@ static status_t parse_payload(private_parser_t *this, payload_type_t payload_typ
pld->destroy(pld);
return PARSE_ERROR;
}
break;
break;
}
case TRANSFORMS:
{
@ -738,7 +738,7 @@ static status_t parse_payload(private_parser_t *this, payload_type_t payload_typ
pld->destroy(pld);
return PARSE_ERROR;
}
break;
break;
}
case TRANSFORM_ATTRIBUTES:
{
@ -748,7 +748,7 @@ static status_t parse_payload(private_parser_t *this, payload_type_t payload_typ
pld->destroy(pld);
return PARSE_ERROR;
}
break;
break;
}
case CONFIGURATION_ATTRIBUTES:
{
@ -758,7 +758,7 @@ static status_t parse_payload(private_parser_t *this, payload_type_t payload_typ
pld->destroy(pld);
return PARSE_ERROR;
}
break;
break;
}
case ATTRIBUTE_FORMAT:
{
@ -789,7 +789,7 @@ static status_t parse_payload(private_parser_t *this, payload_type_t payload_typ
}
attribute_length = *(u_int16_t*)(output + rule->offset);
break;
}
}
case ATTRIBUTE_LENGTH_OR_VALUE:
{
if (this->parse_uint16(this, rule_number, output + rule->offset) != SUCCESS)
@ -820,7 +820,7 @@ static status_t parse_payload(private_parser_t *this, payload_type_t payload_typ
pld->destroy(pld);
return PARSE_ERROR;
}
break;
break;
}
case ID_DATA:
{
@ -830,7 +830,7 @@ static status_t parse_payload(private_parser_t *this, payload_type_t payload_typ
pld->destroy(pld);
return PARSE_ERROR;
}
break;
break;
}
case AUTH_DATA:
{
@ -839,8 +839,8 @@ static status_t parse_payload(private_parser_t *this, payload_type_t payload_typ
{
pld->destroy(pld);
return PARSE_ERROR;
}
break;
}
break;
}
case CERT_DATA:
{
@ -849,8 +849,8 @@ static status_t parse_payload(private_parser_t *this, payload_type_t payload_typ
{
pld->destroy(pld);
return PARSE_ERROR;
}
break;
}
break;
}
case CERTREQ_DATA:
{
@ -859,18 +859,18 @@ static status_t parse_payload(private_parser_t *this, payload_type_t payload_typ
{
pld->destroy(pld);
return PARSE_ERROR;
}
break;
}
break;
}
case EAP_MESSAGE:
case EAP_DATA:
{
size_t data_length = payload_length - EAP_PAYLOAD_HEADER_LENGTH;
if (this->parse_chunk(this, rule_number, output + rule->offset, data_length) != SUCCESS)
{
pld->destroy(pld);
return PARSE_ERROR;
}
break;
}
break;
}
case SPIS:
{

View File

@ -25,6 +25,7 @@
#include "eap_payload.h"
#include <daemon.h>
typedef struct private_eap_payload_t private_eap_payload_t;
@ -54,9 +55,9 @@ struct private_eap_payload_t {
u_int16_t payload_length;
/**
* The contained message.
* EAP message data, if available
*/
chunk_t message;
chunk_t data;
};
/**
@ -80,21 +81,21 @@ encoding_rule_t eap_payload_encodings[] = {
{ RESERVED_BIT, 0 },
{ RESERVED_BIT, 0 },
/* Length of the whole payload*/
{ PAYLOAD_LENGTH, offsetof(private_eap_payload_t, payload_length)},
/* some eap data bytes, length is defined in PAYLOAD_LENGTH */
{ EAP_MESSAGE, offsetof(private_eap_payload_t, message) }
{ PAYLOAD_LENGTH, offsetof(private_eap_payload_t, payload_length) },
/* chunt to data, starting at "code" */
{ EAP_DATA, offsetof(private_eap_payload_t, data) },
};
/*
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ EAP Message ~
! !
! Code ! Identifier ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Type ! Type_Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
*/
/**
@ -102,6 +103,47 @@ encoding_rule_t eap_payload_encodings[] = {
*/
static status_t verify(private_eap_payload_t *this)
{
u_int16_t length;
u_int8_t code;
if (this->data.len < 4)
{
DBG1(DBG_ENC, "EAP payloads EAP message too short (%d)", this->data.len);
return FAILED;
}
code = *this->data.ptr;
length = htons(*(u_int16_t*)(this->data.ptr + 2));
if (this->data.len != length)
{
DBG1(DBG_ENC, "EAP payload length (%d) does not match contained message length (%d)",
this->data.len, length);
return FAILED;
}
switch (code)
{
case EAP_REQUEST:
case EAP_RESPONSE:
{
if (this->data.len < 4)
{
DBG1(DBG_ENC, "EAP Request/Response does not have any data");
return FAILED;
}
break;
}
case EAP_SUCCESS:
case EAP_FAILURE:
{
if (this->data.len != 4)
{
DBG1(DBG_ENC, "EAP Success/Failure has data");
return FAILED;
}
break;
}
default:
return FAILED;
}
return SUCCESS;
}
@ -147,40 +189,59 @@ static size_t get_length(private_eap_payload_t *this)
}
/**
* Implementation of eap_payload_t.set_message.
* Implementation of eap_payload_t.get_data.
*/
static void set_message (private_eap_payload_t *this, chunk_t message)
static chunk_t get_data(private_eap_payload_t *this)
{
if (this->message.ptr != NULL)
{
chunk_free(&(this->message));
}
this->message.ptr = clalloc(message.ptr,message.len);
this->message.len = message.len;
this->payload_length = EAP_PAYLOAD_HEADER_LENGTH + this->message.len;
return this->data;
}
/**
* Implementation of eap_payload_t.get_message.
* Implementation of eap_payload_t.set_data.
*/
static chunk_t get_message (private_eap_payload_t *this)
static void set_data(private_eap_payload_t *this, chunk_t data)
{
return (this->message);
chunk_free(&this->data);
this->data = chunk_clone(data);
this->payload_length = this->data.len + 4;
}
/**
* Implementation of eap_payload_t.get_data_clone.
* Implementation of eap_payload_t.get_code.
*/
static chunk_t get_message_clone (private_eap_payload_t *this)
static eap_code_t get_code(private_eap_payload_t *this)
{
chunk_t cloned_message;
if (this->message.ptr == NULL)
if (this->data.len > 0)
{
return (this->message);
return *this->data.ptr;
}
cloned_message.ptr = clalloc(this->message.ptr,this->message.len);
cloned_message.len = this->message.len;
return cloned_message;
/* should not happen, as it is verified */
return 0;
}
/**
* Implementation of eap_payload_t.get_identifier.
*/
static u_int8_t get_identifier(private_eap_payload_t *this)
{
if (this->data.len > 1)
{
return *(this->data.ptr + 1);
}
/* should not happen, as it is verified */
return 0;
}
/**
* Implementation of eap_payload_t.get_type.
*/
static eap_type_t get_type(private_eap_payload_t *this)
{
if (this->data.len > 4)
{
return *(this->data.ptr + 4);
}
return 0;
}
/**
@ -188,12 +249,8 @@ static chunk_t get_message_clone (private_eap_payload_t *this)
*/
static void destroy(private_eap_payload_t *this)
{
if (this->message.ptr != NULL)
{
chunk_free(&(this->message));
}
free(this);
chunk_free(&this->data);
free(this);
}
/*
@ -202,7 +259,7 @@ static void destroy(private_eap_payload_t *this)
eap_payload_t *eap_payload_create()
{
private_eap_payload_t *this = malloc_thing(private_eap_payload_t);
/* interface functions */
this->public.payload_interface.verify = (status_t (*) (payload_t *))verify;
this->public.payload_interface.get_encoding_rules = (void (*) (payload_t *, encoding_rule_t **, size_t *) ) get_encoding_rules;
@ -214,15 +271,61 @@ eap_payload_t *eap_payload_create()
/* public functions */
this->public.destroy = (void (*) (eap_payload_t *)) destroy;
this->public.set_message = (void (*) (eap_payload_t *,chunk_t)) set_message;
this->public.get_message_clone = (chunk_t (*) (eap_payload_t *)) get_message_clone;