Network Working Group G. Giaretta
Internet-Draft TILab
Expires: August 13, 2005 R. Lopez
Univ. of Murcia
Y. Ohba (Ed.)
TARI
S. Thomson
Cisco
H. Tschofenig
Siemens
February 12, 2005
Usage Scenarios and Requirements for Multi-hop EAP Lower Layer
draft-ohba-multihop-eap-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 August 13, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Giaretta, et al. Expires August 13, 2005 [Page 1]
Internet-Draft Multi-hop EAP February 2005
All EAP lower layers that have been defined for network access
authentication have the requirement that an EAP peer and an EAP
authenticator are in the same IP subnet. This draft describes some
scenarios where relaxing this requirement so that the EAP peer and
the EAP authenticator are multiple IP hops away from each other could
be useful or necessary. The draft also extracts a set of
requirements for the design of such a multi-hop EAP lower layer based
on the scenarios.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Multi-hop EAP Scenarios . . . . . . . . . . . . . . . . . . . 4
2.1 Network access control protocol . . . . . . . . . . . . . 4
2.2 Media-independent pre-authentication . . . . . . . . . . . 5
2.3 MIPv6 bootstrapping by running PANA . . . . . . . . . . . 6
2.3.1 Relaxing PANA Assumptions . . . . . . . . . . . . . . 6
2.3.2 Bootstrapping Issues . . . . . . . . . . . . . . . . . 7
2.4 Service Authorization and Bootstrapping . . . . . . . . . 8
2.5 Mobile ad-hoc networks (MANET) and infrastructure
authentication . . . . . . . . . . . . . . . . . . . . . . 12
3. Mutihop EAP Requirements . . . . . . . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1 Normative References . . . . . . . . . . . . . . . . . . . . 18
6.2 Normative References . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . 22
Giaretta, et al. Expires August 13, 2005 [Page 2]
Internet-Draft Multi-hop EAP February 2005
1. Introduction
The Extensible Authentication Protocol (EAP) [RFC3748] was designed
to enable extensible authentication for network access in situations
in which the IP protocol is not available. Originally developed for
use with PPP [RFC1661], it has also been applied to IEEE 802 wireless
networks [IEEE8021X]. Moreover, PANA [I-D.ietf-pana-pana] defines a
new EAP lower layer that uses IP between the protocol end points;
with PANA, therefore, EAP authentication framework can also be used
on any link that can carry IP.
All EAP lower layers defined for network access authentication so far
have the requirement that an EAP peer and an EAP authenticator are in
the same IP subnet: this is obvious for layer-2 EAP lower layers
(e.g. IEEE802.1X), but it is the case also of PANA, which explicitly
requires that the PaC (PANA Client) and the PAA (PANA Authentication
Agent) are one IP hop away.
However, recently there has been some interest to relax this
requirement and to design an EAP lower layer in order to enable new
scenarios and applications where EAP framework can be used. These
scenarios are quite different from each others: some of them are
still related to network access authentication, whereas others imply
that EAP is used as the authentication protocol for a purpose
different from the network access (e.g. for bootstrapping a
service). On the other hand, all those scenarios are identified with
a specific EAP lower layer functionality to carry EAP messages
between the EAP peer and the EAP authenticator over multiple IP hops.
An EAP lower layer that has such a functionality is referred to as a
"multi-hop EAP lower layer".
The purpose of this draft is to describe some scenarios where a
multi-hop EAP lower layer could be useful or necessary and, based on
them, to list a set of requirements for the design of such a
multi-hop EAP lower layer.
Giaretta, et al. Expires August 13, 2005 [Page 3]
Internet-Draft Multi-hop EAP February 2005
2. Multi-hop EAP Scenarios
2.1 Network access control protocol
The Network Access Control Protocol (NACP) [I-D.thomson-nacp] has
been designed to carry EAP payloads [RFC3748] over a UDP transport
between a peer and authenticator for the purposes of enforcing access
control at a particular device in the network.
To date, NACP has been targeted at enterprise deployment scenarios,
where it cannot be assumed that the peer and authenticator are one L3
hop way from each other. While first hop deployment scenarios may be
common and may need to be optimized for, the protocol must be
flexible enough to accommodate deployments where the peer and
authenticator are more than one hop away from one another. Examples
of multi-hop deployment scenarios include the following:
1. Network access control may be enforced at the boundaries between
network domains e.g. at the border between a less trusted/
managed branch office and main campus, at the border between main
campus and gateway to the Internet, at the border between
extranet and intranet, and on access to protected servers in a
data center.
2. While first hop deployments may be highly desirable, it may not
be possible in all cases. The first-hop router may not support
authenticator functionality e.g. in SOHO deployment scenarios,
or there may be a transition period in a customer deployment
before all first-hop devices have been upgraded to support the
new functionality.
3. There may be multiple authenticators in a network, each
responsible for making different kinds of checks on a host and
potentially making different authorization decisions. An
authenticator may be present at the first L3 hop to enforce a
minimal level of compliance with security policy, while another
authenticator at a different point in the network may be
responsible for enforcing a stricter level of compliance where
more restrictive access is needed.
PANA [I-D.ietf-pana-pana] is a protocol that also encapsulates EAP
over a UDP transport. One of the remaining differences in
requirements between NACP and PANA is the need to allow for multi-hop
operation. In particular, PANA enforces single hop operation by
requiring that the TTL field in the IP packet be set appropriately.
Such a requirement would need to be relaxed to support multi-hop
scenarios.
Giaretta, et al. Expires August 13, 2005 [Page 4]
Internet-Draft Multi-hop EAP February 2005
2.2 Media-independent pre-authentication
Media-independent Pre-Authentication (MPA) is a mobile-assisted,
secure mobility optimization scheme that works over any link-layer
and with any mobility management protocol and supports not only
inter-subnet handovers but also and inter-administrative-domain
handovers [MPA]. With MPA, a mobile node is not only able to
securely obtain an IP address and other configuration parameters from
a candidate target network where the mobile may move in the near
future, but also able to send and receive IP packets using the
obtained IP address and other configuration parameters through its
currently attached network before it attaches to the candidate target
network. This makes it possible for the mobile node to complete the
binding update of any mobility management protocol and use the new
care-of address before performing a handover at link-layer.
It is essential for MPA in terms of security that authentication is
taken place between the mobile node in the current network and the
candidate target network, before the mobile node obtains an IP
address and other configuration parameters from the candidate target
network. In MPA, the authentication is performed between the mobile
node and an authentication agent in the candidate target network
using an authentication protocol. The authentication protocol MUST
be able to derive a key between the mobile node and the
authentication agent and SHOULD be able to provide mutual
authentication. The authentication protocol SHOULD be able to
interact with a AAA protocol such as RADIUS and Diameter to carry
authentication credentials to an appropriate authentication server in
the AAA infrastructure. An authentication protocol that carries EAP
naturally would satisfy those requirements. On the other hand, such
an EAP-capable authentication protocol MUST work over IP layer and
over multiple IP hops, since the candidate target network is
different from the current network of the mobile node.
IKEv2 [I-D.ietf-ipsec-ikev2] is able to carry EAP and work over
multiple IP hops. On the other hand, using IKEv2 as the
authentication protocol for MPA might be a burden for the following
reason. Since IKEv2 requires Diffie-Hellman key exchange, the mobile
node would need to perform Diffie-Hellman key exchange with each of
the candidate target networks even if it does not finally make a
decision to move to the candidate target networks.
PANA [I-D.ietf-pana-pana] is another existing protocol that carries
EAP and works over IP layer, but the PANA protocol needs to be
extended to work over multiple IP hops. On the other hand,
considering that PANA does not require Diffie-Hellman key exchange
(this is the case when an EAP authentication method which does not
use Diffie-Hellman to derive an EAP Master Session Key), it might be
Giaretta, et al. Expires August 13, 2005 [Page 5]
Internet-Draft Multi-hop EAP February 2005
worth considering some extension of the PANA protocol to work over
multiple IP hops for MPA than using IKEv2.
2.3 MIPv6 bootstrapping by running PANA
The MIPv6 bootstrapping problem as described in
[I-D.ietf-mip6-bootstrap-ps] involves bootstrapping of the following
parameters:
o MN finding HA's address
o MN obtaining HoA
o Setting an IPsec security association (SA) between the MN and the
HA
Recently the MIP6 working group has expressed a fair amount of
interest in developing another Mobile Node <--> Home Agent Binding
Update security solution. The currently proposed solution
[I-D.ietf-mip6-auth-protocol] (referred as MIP6-Auth-Protocol)
heavily focuses on one specific authentication and key exchange
protocol. This protocol requires that the entire message exchange is
finished in a single roundtrip with the mobile node initiating the
exchange. Obviously, this approach suffers from some limitations.
This document investigates the usage of an Extensible Authentication
Protocol (EAP) [RFC3748] based approach which offers more
flexibility. As in other areas there is the 'one size does not fit
all' problem.
With these recent developments in the MIP6 working group with a
possible usage of the bootstrapping protocol for authentication and
security association establishment it seems to be resonable to modify
the goal of the MIPv6 bootstrapping in the sense that a security
association has to be established between the mobile node and the
home agent for protection of the MN <--> HA Binding Update to enable
the usage of [I-D.ietf-mip6-auth-protocol] in addition to the
establishment of IPsec SAs.
2.3.1 Relaxing PANA Assumptions
PANA was designed with a focus on network access authentication.
This fact is reflected in the discovery mechanism whereby a
link-local multicast address is used [I-D.ietf-pana-pana]. It is
assumed that the PAA is only one IP hop away from the PaC. This
assumption is based on today's network access protocols and the
observation that in many networks the administrative boundaries can
be draw between the end host and the access network.
Giaretta, et al. Expires August 13, 2005 [Page 6]
Internet-Draft Multi-hop EAP February 2005
This assumption is not applicable to this environment. The PaC might
address the PAA directly via a unicast message over multiple IP hops
or a new discovery message needs to be added. In the former case the
PAA would be co-located with the home agent. From a protocol design
point of view it seems to be reasonable to communicate only between
nodes that are effected in the protocol rather than arbitrary nodes
and thereby imposing artifical deployment constraints.
2.3.2 Bootstrapping Issues
We assume that the MN will act as a PaC and some agent in the network
will act as the PAA, most likely the home agent itself. After mutual
authentication, a security association will be established between
PaC and the HA, which is comparable to an enforcement point (EP).
Note, the PAA and the EP may be co-located as well.
2.3.2.1 Home Agent Discovery
Finding the address of the HA will be regarded as out of scope of
this document. The MN could learn about the HA either by manual
configuration, DNS or some other mechanism (such as the MIPv6 anycast
mechanism). Even a discovery mechanism using a Router Alert Option
alike mechanisms, which is added to PANA, might be possible. This
aspect is for further investigation.
2.3.2.2 Obtaining HoA
The payload of any PANA message consists of zero or more Attribute
Value Pairs (AVP). [I-D.ietf-pana-pana] describes a number of AVPs
for different purposes. This draft proposes a new AVP for carrying
the HoA of the MN.
HoA AVP: Contains the MIPv6 home address of the mobile node that
wishes to setup a security association with the corresponding home
agent. The HoA AVP is integrity protected by PANA and either
randomly selected or selected based on user authentication.
To deal with UDP encapsulation in case of NAT traversal or even with
IPv4/IPv6 transition the same procedure as suggested with an
extension for IKEv1 [RFC3947] and in IKEv2 [I-D.ietf-ipsec-ikev2] can
be applied. Support for this functionality requires the introduction
of a new AVP in PANA. In context of IPv4/IPv6 transition scenario
this proposal provides an alternative solution for a tunnel broker
(see also [I-D.blanchet-v6ops-tunnelbroker-tsp] for a different
approach using SASL).
2.3.2.3 MN-HA security association
As motivated in [I-D.ietf-mip6-bootstrap-ps] a security association
Giaretta, et al. Expires August 13, 2005 [Page 7]
Internet-Draft Multi-hop EAP February 2005
is required for subsequent protection of Mobile IPv6 Binding Update
messages sent between the MN and the HA. We refer to this security
association as the MIPv6 SA. Since the details of the
MIPv6-Auth-Protocol [I-D.ietf-mip6-auth-protocol] are subject to
change we assume that the following parameters have to be established
as part of the bootstrapping procedure:
o Security Parameter Index (SPI) - possibly for both directions
o Replay Protection Parameter (such as a timestamp or a sequence
number)
o Algorithms (if a negotiation procedure is desired)
Finally, a session key needs to be derived. Since a PANA SA needs to
be established based on the EAP method provided session key it is
also useful to apply the same procedure for deriving a session key
for the MIPv6 SA. The PANA protocol [I-D.ietf-pana-pana] describes
the session key derivation for the PANA SA.
It might be worth noting that the PANA protocol also allows rekeying
of the security association (both the PANA SA and the MIPv6 SA). The
PANA protocol discusses this aspect in the context of
re-authentication.
The lifetime of the MIPv6 SA can either be negotiated or indicated by
the MN's home network. As another alternative the periodic
retransmission of "refresh" messages is benefial to deal with NATs,
stateful packet filtering firewalls and orphan state at the HA. PANA
provides such a refresh message as described in Section 4.5 of
[I-D.ietf-pana-pana]. Furthermore, a Session-Lifetime AVP is offered
by PANA as described in Section 4.10 of [I-D.ietf-pana-pana].
Since PANA is an extensible protocol it is possible to use a single
protocol for bootstrapping IPsec SAs (as described in
[I-D.ietf-pana-ipsec]) and a security association for
[I-D.ietf-mip6-auth-protocol].
2.4 Service Authorization and Bootstrapping
EAP [RFC3748] was designed and used so far for network access
authentication and authorization. With IEEE 802.1X and IEEE 802.11i
EAP and the corresponding EAP methods are used to "bootstrap" keying
material for link layer security. In IKEv2, EAP is used although the
EAP method provided keying material is not feed into the generation
of keying material for IPsec SA establishment. The Diffie Hellman
keying material is used instead. Using PANA the MSK/AAA-Key provided
Giaretta, et al. Expires August 13, 2005 [Page 8]
Internet-Draft Multi-hop EAP February 2005
by EAP methods is used to derive keying material that might be used
for bootstrapping link layer or even network layer security
associations.
Due to several advantages brought by EAP framework, in a similar way
it could be advantageous to use EAP for service authorization and
bootstrapping. Actually several services need to be bootstrapped
setting up a security association between the node providing the
service and the node using it. For example, see
[I-D.ietf-mip6-bootstrap-ps] for the problem statement for Mobile
IPv6 bootstrapping. Unfortunately, since the involved entities (i.e.
bootstrapping and bootstrapped nodes) are usually more than one IP
hop away, using EAP for authorization and bootstrapping purposes
implies that EAP packets must be carried in a multi-hop environment.
A possible approach could be the usage of IKEv2 since, as mentioned
before, it already supports EAP authentication; nonetheless IKEv2
only creates IPsec SAs since the concept of Domain of Interpretations
(DoIs) was removed due to the limited usage in IKEv1. An alternative
approach is the usage of PANA which has been designed with
extensibility in mind. There is, however, the need to relax the
requirement that the PaC and the PAA must be one IP hop away, as
suggested in [I-D.tschofenig-mip6-bootstrapping-pana]. This was
mainly motivated by the usage of network access authentication
protocol found today.
This section briefly describes a framework for service authorization
and bootstrapping that would be advantageous as soon as a multi-hop
EAP lower layer is designed. Figure 1 depicts the framework
architecture; the nodes involved are:
o the bootstrapped node (BN) which is the node triggering the
service bootstrapping;
o the Service Provider Node (SPN) which is the node providing the
service (e.g. the Home Agent in Mobile IPv6). This node acts as
an EAP authenticator and it may handle the authentication locally
or it may act as a pass-through to a backend authentication
server;
o the backend authentication server (AAA server in Figure 1) which
verifies the BN's credentials and authorizes the user for a
particular service.
Giaretta, et al. Expires August 13, 2005 [Page 9]
Internet-Draft Multi-hop EAP February 2005
BN SPN AAA server
---- ----- ------------
<------PANA multi-hop------> <-----Diameter------->
<-------------------------EAP---------------------->
Figure 1: Service Authorization and Bootstrapping through EAP
If a backend authentication server is needed, the bootstrapping
procedure consists of two phases:
o Discovery Phase: the BN discovers through an out-of-band mechanism
(e.g. pre-configuration, DNS, anycast addresses) a SPN for the
particular service it wants to activate;
o Authorization and Configuration Phase: during this phase an EAP
exchange occurs between the BN and the AAA server, the SPN acting
as a pass-through EAP authenticator. This exchange is needed to
verify the credentials of the BN in order to authorize the
service. Moreover during this phase, depending on the service
configuration peculiarities, an exchange of configuration and
authorization parameters between the BN and the AAA server or the
SPN could be necessary: this can be accomplished through EAP lower
layers and AAA protocol AVPs (e.g. PANA and Diameter AVPs).
o The approach depicted in Figure 1 could be generalized as shown in
Figure 2 in order to bootstrap several services through a single
EAP exchange. For this purposes a new node, the Service
Authorization Anchor Point (SAAP) has been introduced. The BN
starts an EAP exchange with the SAAP and asks for a set of
services; the SAAP may act as a pass-through EAP authenticator or
it may locally authenticate and authorize the users. Finally the
SAAP gets in touch with the involved SPNs and sends them the
authorization result and the necessary configuration parameters.
As shown in Figure 2, PANA can be used as a protocol for interacting
with a that allows bootstrapping of credentials. One example of such
credentials that can be dynamically created based on an EAP
authentication and authorization protocol run was shown in
[I-D.tschofenig-pana-bootstrap-kerberos]. Kerberos [RFC1510] is a
well-known security protocol which provides authentication,
authorization and key distribution. It is used to secure a number of
protocols. By combining the flexibility of the EAP framework with
the wide deployment of Kerberos in universitites and corporate
networks it is possible to bootstrap a Kerberos Ticket Granting
Ticket. This Kerberos Ticket Granting Ticket can then be used to
retrieve service tickets for usage with a variety of protocols. This
Giaretta, et al. Expires August 13, 2005 [Page 10]
Internet-Draft Multi-hop EAP February 2005
approach of bootstrapping Kerberos ticket with the help of an EAP
protocol interaction is described in
[I-D.tschofenig-pana-bootstrap-kerberos].
Another approach to combine EAP and Kerberos is to integrate an
EAP-based pre-authentication mechanism into Kerberos. However, using
a generic protocol for bootstrapping credentials can also be used for
bootstrapping symmetric keys for usage Mobile IP (as discussed as
part of the MIPv6 bootstrapping work [I-D.ietf-mip6-bootstrap-ps]) or
also to bootstrap public/private keys. Therefore, it would be
necessary to confidentiality protect the delivery of an ephemeral
public and private key pair to the end host. This key pair would
have a short lifetime, possibly without the need for revocation
mechanisms, and could be used in all security protocols utilizing
public key based mechanisms (including IKEv2 or TLS). A big
advantage is the avoided public key infrastructure since
authentication protocols based on symmetric cryptography can still be
used within EAP.
As part of the bootstrapping activity it might be necessary to
exchange parameters and authorization information between the
Bootstrapped Node and the Service Authorization Anchor Point (SAAP)
for later communication between the Bootstrapped Node and a Service
Provider Node. This information might again require confidentiality
protection as, for example, illustrated in
[I-D.tschofenig-enroll-bootstrapping-saml].
Giaretta, et al. Expires August 13, 2005 [Page 11]
Internet-Draft Multi-hop EAP February 2005
<-------------------------------EAP----------------------------->
BN SAAP AAA server
---- ------ ------------
<---PANA multi-hop---> ^ <-------Diameter-------> ^
| |
--- --- --- ---
| | | |
v v v v
SPN1 SPN2 SPN3 SPN4
Figure 2: Service Authorization Anchor Point
2.5 Mobile ad-hoc networks (MANET) and infrastructure authentication
Mobile Ad-Hoc Networks (MANET) are envisioned to have dynamic,
sometimes rapidly-changing, random, multi-hop topologies which are
likely composed of relatively bandwidth-constrained wireless links.
One of the challenges which are being dealt with within the MANET
community is the Internet connectivity for ad-hoc networks.
Supporting global Internet connectivity for mobile ad-hoc networks is
also useful because ad-hoc nodes inside a manet may want to
communicate with nodes outside the MANET which are located somewhere
in Internet. Some alternatives describe how to obtain a globally
router address and Internet-gateway (GW) operation
[I-D.wakikawa-manet-globalv6],
[I-D.jelger-manet-gateway-autoconf-v6], [I-D.perkins-manet-aodvbis],
[I-D.cha-manet-extended-support-globalv6],
[I-D.ruiz-manet-mcast-gw-reqs] both for IPv4 and IPv6 connectivity.
Giaretta, et al. Expires August 13, 2005 [Page 12]
Internet-Draft Multi-hop EAP February 2005
+-----------------------------+ +------------------------------------+
| MANET | | NAP/ISP |
| +---------+ +-------+ +-----------+ +----------+ |
| +-----+ AdNode 2+----+ GW +---+ auth agent|---|AAA Server| |
| | +---------+ +-------+ +-----------+ +----------+ |
| +---+-----+ | | |
| |AdNode 1 | | | |
| +---------+ | | |
| ^ | | |
+----------+------------------+ +------------------------------------+
|
+---+----+
| AdNode |
+--------+
Figure 3: MANET + Infrastructure user authentication
The objective is to allow sending and/or receiving data traffic from
Infrastructure side to any ad-hoc node attached to MANET. It is
achieved through a gateway (GW) that is acting as another ad-hoc node
in the MANET side and that belongs to the Infrastructure in the other
side. In some scenarios, it MAY be required that only authenticated
and authorized ad-hoc nodes can send data traffic to Internet. In
order to achieve that, a mutual authentication process MUST be
executed between a mobile ad-hoc node and authentication agent (AA).
This authentication agent could be co-located or not in the GW
depending on network management policies. Additionally
authentication agent could need to interact with a backend AAA
server.
EAP provides a flexible way to authenticate to entities (in
particular ad-hoc nodes) because supports multiple authentication
methods. EAP key management framework defines interactions between
EAP peers (ad-hoc nodes in this scenario) authentication agents and
AAA server. Following [I-D.ietf-eap-keying], on the one hand AAA
protocols such as RADIUS or Diameter can be used to transport EAP
between authentication agent and AAA server. On the other hand, EAP
lower layer should be able to work over IP layer and multiple IP hop
where each ac-hoc node and GW define a new hop.
Note that, in some cases, ad-hoc network MAY be considered as an
un-secure link and a security association between ad-hoc node and GW
MAY be needed for data traffic sent/received to/from the Internet.
IPsec MAY be a choice.
Initially several alternatives are being considered (but not limited
to):
Giaretta, et al. Expires August 13, 2005 [Page 13]
Internet-Draft Multi-hop EAP February 2005
o IKEv2 [I-D.ietf-ipsec-ikev2] that is able to transport EAP packets
could be used between ad-hoc node and GW between multiple hops.
IKEv2 is worth to be used when:
* IPSec SA needs to be established between ad-hoc node and GW for
data addressed to Internet and
* Authentication Agent is co-located on GW
o PANA is also another protocol that is able to carry EAP and works
over IP layer though currently it is not working in multi-hop
scenarios. However, it is worth to make some modifications that
allow to PANA works in multiple IP hop for several reasons:
* It would allow Authentication Agent is not co-located in the GW
* It would avoid to ad-hoc node (in general with limited
computational resources) always performs Diffie-Hellman key
exchange
Additionally note that several methods providing a prefix to ad-hoc
nodes to allow them to configure IP global address can be find in
references (i.e. [I-D.wakikawa-manet-globalv6],
[I-D.jelger-manet-gateway-autoconf-v6]).It would be interesting for
the sake of flexibility that multi hop-EAP lower layer will inform
about what method must be used with a particular GW. For example,
PANA provides that by using Post-PANA-Address-Configuration (PPAC)
AVP.
Nevertheless further study must be done in order to determine that
option could be considered more suitable taking into account special
MANET features.
Giaretta, et al. Expires August 13, 2005 [Page 14]
Internet-Draft Multi-hop EAP February 2005
3. Mutihop EAP Requirements
This section describes requirements for a multi-hop EAP lower layer.
In addition to the EAP lower layer requirements described in the EAP
specification [RFC3748], a multi-hop EAP lower layer needs to satisfy
the following requirements.
o A multi-hop EAP lower-layer MUST be able to establish an SA to
subsequently provide integrity protection and replay protection
for its later message exchange. It MUST be able to use EAP
methods to establish keys from the EAP key hierarchy to create the
SA.
o A multi-hop EAP lower-layer MUST be able to bootstrap SAs used for
securing services that are not limited to simple network access
services. The SAs MUST include not only IKE and IPsec SAs but
also other types of SAs.
o A multi-hop EAP lower-layer MUST be able to carry service
authorization parameters.
o A multi-hop EAP lower-layer SHOULD be specified with some
out-of-band mechanism for an EAP peer to find its communicating
EAP authenticator.
o A multi-hop EAP lower-layer MUST have a mechanism for NAT
traversal.
Giaretta, et al. Expires August 13, 2005 [Page 15]
Internet-Draft Multi-hop EAP February 2005
4. Security Considerations
This document describes usage scenarios and requirements for running
EAP over multiple IP hops between an EAP peer and an EAP
authenticator. All security threats discussed in
[I-D.ietf-pana-threats-eval] for the case where an EAP peer and an
EAP authenticator are one IP hop away from each other and EAP is used
for network access authentication apply to the usage scenarios and
requirements described in this document. In the case of multi-hop
EAP environments, the PANA requirement of binding the authenticated
session to the device identifier of the client to mitigate service
theft [I-D.ietf-pana-threats-eval] can make a denial of servcie (DoS)
attack of preventing a legitimate client from binding its device
identifier to the authenticated session easier because the device
identifier of the client may not appear in the encapsulating header
of the EAP lower layer messages. For example, when PANA is used as
the multi-hop EAP lower layer and MAC address is used as the device
identifier, an attacker PaC can put some other PaC's device
identifier in a PANA Device-Id AVP while using its own MAC address in
the encapsulating MAC header the PANA message. Since the PAA that is
more than one IP hop away from the attacker is not able to see the
original MAC header of the PANA message, a simple comparison of the
Device-Id AVP against the device identifier contained in the MAC
header does not work. This may require a cryptographic binding
between the authenticated session and the device identifier of the
client to be created outside the PANA protocol.
There is another type of security threats that are not addressed in
[I-D.ietf-pana-threats-eval] and are related to the usage where an
EAP lower layer is used for carrying authorization parameters.
Eavesdropping of the authorization parameters is an issue if the
authorization parameters contain privacy information without
encryption. Theft of the authorization parameters is another issue
if the authorization parameters are carried without encryption and
there is no mechanism for cryptographically limiting the use of the
authorization parameters to the authorized client only. If the
authorization parameters are carried without integrity protection, a
DoS attack based on by altering the authorization parameters is
possible.
Giaretta, et al. Expires August 13, 2005 [Page 16]
Internet-Draft Multi-hop EAP February 2005
5. Acknowledgments
o General acknowledgments: The authors would like to thank Joseph
Salowey for his valuable comments on the draft.
o Acknowledgments on Section 2.3: Section 2.3 is a byproduct of the
Ambient Networks Project, partially funded by the European
Commission under its Sixth Framework Programme. Section 2.3 is
provided "as is" and without any express or implied warranties,
including, without limitation, the implied warranties of fitness
for a particular purpose. The views and conclusions contained in
Section 2.3 are those of the authors and should not be interpreted
as necessarily representing the official policies or endorsements,
either expressed or implied, of the Ambient Networks Project or
the European Commission.
o Acknowledgments on Section 2.5: The authors thank to Antonio
F.Gomez Skarmeta and Pedro M.Ruiz for valuable comments for
Section 2.5.
Giaretta, et al. Expires August 13, 2005 [Page 17]
Internet-Draft Multi-hop EAP February 2005
6. References
6.1 Normative References
[I-D.ietf-pana-pana]
Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A.
Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", draft-ietf-pana-pana-07 (work in
progress), December 2004.
[I-D.ietf-pana-threats-eval]
Parthasarathy, M., "Protocol for Carrying Authentication
and Network Access Threat Analysis and Security
Requirements", draft-ietf-pana-threats-eval-07 (work in
progress), August 2004.
[I-D.ietf-ipsec-ikev2]
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-17 (work in progress), October
2004.
[I-D.ietf-mip6-bootstrap-ps]
Patel, A., "Problem Statement for bootstrapping Mobile
IPv6", draft-ietf-mip6-bootstrap-ps-01 (work in progress),
October 2004.
[I-D.ietf-mip6-auth-protocol]
Leung, K., "Authentication Protocol for Mobile IPv6",
draft-ietf-mip6-auth-protocol-04 (work in progress),
February 2005.
[I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-04 (work in
progress), November 2004.
[I-D.ietf-pana-ipsec]
Parthasarathy, M., "PANA enabling IPsec based Access
Control", draft-ietf-pana-ipsec-05 (work in progress),
December 2004.
[RFC3947] Kivinen, T., Swander, B., Huttunen, A. and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
Giaretta, et al. Expires August 13, 2005 [Page 18]
Internet-Draft Multi-hop EAP February 2005
[I-D.tschofenig-mip6-bootstrapping-pana]
Tschofenig, H., Bournelle, J. and S. Thiruvengadam,
"Bootstrapping Mobile IPv6 using PANA",
draft-tschofenig-mip6-bootstrapping-pana-00 (work in
progress), October 2004.
[I-D.wakikawa-manet-globalv6]
Wakikawa, R., "Global Connectivity for IPv6 Mobile Ad Hoc
Networks", draft-wakikawa-manet-globalv6-03 (work in
progress), October 2003.
[I-D.perkins-manet-aodvbis]
Perkins, C., "Ad hoc On-Demand Distance Vector (AODV)
Routing", draft-perkins-manet-aodvbis-01 (work in
progress), February 2004.
[I-D.jelger-manet-gateway-autoconf-v6]
Jelger, C., "Gateway and address autoconfiguration for
IPv6 adhoc networks",
draft-jelger-manet-gateway-autoconf-v6-02 (work in
progress), April 2004.
[I-D.cha-manet-extended-support-globalv6]
Cha, H., Park, J. and H. Kim, "Extended Support for Global
Connectivity for IPv6 Mobile Ad Hoc Networks",
draft-cha-manet-extended-support-globalv6-00 (work in
progress), October 2003.
[I-D.thomson-nacp]
Thomson, S., "Network Access Control Protocol (NACP)",
draft-thomson-nacp-00 (work in progress), October 2004.
[MPA] Anjum, F., Das, S., Dutta, A., Fajardo, V., Madhani, S.,
Ohba, Y., Taniuchi, K., Yaqub, R. and T. Zhang, "A
proposal for MIH function and Information Service",
January 2005.
6.2 Normative References
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[I-D.blanchet-v6ops-tunnelbroker-tsp]
Parent, F. and M. Blanchet, "IPv6 Tunnel Broker with the
Tunnel Setup Protocol(TSP)",
draft-blanchet-v6ops-tunnelbroker-tsp-01 (work in
progress), June 2004.
Giaretta, et al. Expires August 13, 2005 [Page 19]
Internet-Draft Multi-hop EAP February 2005
[I-D.ruiz-manet-mcast-gw-reqs]
Ruiz, P., "Requirements for MANET Interworking with Wired
Multicast Networks", draft-ruiz-manet-mcast-gw-reqs-00
(work in progress), February 2004.
[IEEE8021X]
"Port-Based Network Access Control", IEEE Standard for
Local and Metropolitan Area Networks IEEE Std 802.1X-2004.
[RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993.
[I-D.tschofenig-pana-bootstrap-kerberos]
Tschofenig, H., "Bootstrapping Kerberos",
draft-tschofenig-pana-bootstrap-kerberos-00 (work in
progress), July 2004.
[I-D.tschofenig-enroll-bootstrapping-saml]
Tschofenig, H., Giaretta, G. and A. Gomez-Skarmeta,
"Enriching Bootstrapping with Authorization Information",
draft-tschofenig-enroll-bootstrapping-saml-00.txt (work in
progress), February 2005.
Authors' Addresses
Gerardo Giaretta
Telecom Italia Lab
via G. Reiss Romoli, 274
TORINO, 10148
Italy
Phone: +39 011 2286904
EMail: gerardo.giaretta@tilab.com
Rafael Marin Lopez
University of Murcia
30071 Murcia
Spain
EMail: rafa@dif.um.es
Giaretta, et al. Expires August 13, 2005 [Page 20]
Internet-Draft Multi-hop EAP February 2005
Yoshihiro Ohba
Toshiba America Research, Inc.
1 Telcordia Drive
Piscataway, NJ 08854
USA
Phone: +1 732 699 5305
EMail: yohba@tari.toshiba.com
Susan Thomson
Cisco Systems
499 Thornall St, floor 8
Edison, NJ 08837
USA
EMail: sethomso@cisco.com
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
EMail: Hannes.Tschofenig@siemens.com
Giaretta, et al. Expires August 13, 2005 [Page 21]
Internet-Draft Multi-hop EAP February 2005
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 (2005). 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.
Giaretta, et al. Expires August 13, 2005 [Page 22]