Internet DRAFT - draft-engelstad-pana-eap-over-ip
draft-engelstad-pana-eap-over-ip
Internet Draft P. Engelstad
Telenor R&D
Expires July 2002 January 2002
Extensible Authentication Protocol over IP (EAPoIP)
<draft-engelstad-pana-eap-over-ip-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
This document is an Internet-Draft. 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 document is an individual submission for the PANA Working Group
of the Internet Engineering Task Force (IETF). Comments should be
submitted to the mailing list pana@research.telcordia.com.
Abstract
This document specifies the Extensible Authentication Protocol over
IP (EAPoIP) to be used as a carrier for network access
authentication. An access domain is represented by one or many PANA
Authentication Agents (PAAs). Before a host is granted access to the
domain, a PAA can use EAPoIP to authenticate the host. The host can
also use EAPoIP to authenticate the PAA. EAPoIP is essentially a
variation of the Extensible Authentication Protocol (PPP EAP) [2]
and runs over IP - either IPv4 or IPv6. Unlike PPP EAP, EAPoIP
allows hosts and PAAs to authenticate over any link layer
technology, and they do not need to be on the same link. Since
EAPoIP is basically a client/server protocol, and since the PANA WG
is opting for a lightweight solution, UDP is proposed as the
transport protocol for EAPoIP.
P. Engelstad Expires July 2002 [Page 1]
EAP over IP February 2002
Table of Contents
1 Introduction.....................................................2
2 Terminology......................................................3
3 UDP as a transport protocol for EAPoIP...........................3
4 EAPoIP re-uses PPP EAP message formats...........................3
5 A simplified model of a "host-initiated" EAPoIP scheme...........4
6 A simplified model of a "network-initiated" EAPoIP scheme........6
7 Identity hiding..................................................6
8 Additional Security Requirements.................................7
9 Retransmission and timeout mechanisms............................7
10 Security Considerations.........................................7
IANA Considerations................................................7
Acknowledgements...................................................7
References.........................................................7
Authors' Addresses.................................................8
1 Introduction
This document specifies the Extensible Authentication Protocol over
IP (EAPoIP) to be used as a carrier for network access
authentication.
An access domain is represented by one or many PANA Authentication
Agents (PAAs). Before a host is granted access to the domain, a PAA
MAY use EAPoIP to authenticate the host. The host MAY also use
EAPoIP to authenticate the PAA.
EAPoIP MAY initially be used to establish a local security
association (e.g. in terms of a session key) between a host and a
PAA. A PAA MAY subsequently use EAPoIP to (re-) authenticate a host,
and a host MAY also use EAPoIP to (re-) authenticate a PAA.
EAPoIP is essentially a variation of the Extensible Authentication
Protocol (PPP EAP) [2]. Unlike PPP EAP, EAPoIP runs over IP - either
IPv4 or IPv6. Thus, it allows hosts and PAAs to authenticate over
any link layer technology, and they do not need to be on the same
link.
EAPoIP need to use a transport protocol. Since EAPoIP is basically a
client/server protocol, and since the PANA WG is opting for a
lightweight solution, UDP is proposed. EAPoIP, as outlined in this
document, MAY readily be modified to use TCP or SCTP as transport
protocols. ICMP, on the other hand, seems inappropriate, since PAA
is not concerned with routing.
EAPoIP assumes that the host has configured a valid IPv4 or IPv6
address for itself. It MAY also have discovered IP-addresses of PAAs
in the access domain. A PAA Discovery mechanism is proposed in [1].
P. Engelstad Expires July 2002 [Page 2]
EAP over IP February 2002
Where to locate PAAs (e.g. with a PAA located on each access router
or with a pool of PAAs located further "back" in the access domain)
represents an architectural tradeoff. The PANA WG may leave up to
the implementers and operators which architecture would best fit
their needs. Alternatively, the PANA WG may mandate that PAAs are
located on access routers. The scheme presented in this document
does not mandate any particular architecture; it should accommodate
all possible PAA configurations.
2 Terminology
This document uses the following terms:
Authenticator: A node requiring the authentication, like a PPP
EAP authenticator ([2], [3]).
Peer: A node that is being authenticated by an authenticator,
like a PPP EAP peer ([2], [3]).
PANA Authentication Agent (PAA): The authentication server
function. It acts as an EAP Authenticator that authenticates a
host, or as an EAP Peer that is authenticated by a host.
3 UDP as a transport protocol for EAPoIP
This document suggests that EAPoIP uses UDP as a transport protocol.
Considering PANA WG's preference for a lightweight solution UDP and
ICMP are both attractive alternatives. Since EAPoIP is basically a
stateful client/server protocol, UDP is thus proposed.
(The intention of ICMP in the original IP architecture was to allow
routers to send error and control messages to other routers and
hosts. Since the PAA function is not concerned with routing of any
sort, ICMP is ruled out as an alternative.)
The EAPoIP protocol, as described in this document, can readily be
modified to use more heavyweight transport protocols, such as TCP or
SCTP.
EAPoIP SHOULD use IANA-assigned port numbers (TBD).
4 EAPoIP re-uses PPP EAP message formats
EAPoIP messages re-uses PPP EAP packet formats ([2], [3]).
Thus, EAPoIP MUST support the four message types "Request",
"Response", "Success" and "Failure" with the corresponding code
values 1, 2, 3, and 4, respectively.
P. Engelstad Expires July 2002 [Page 3]
EAP over IP February 2002
Furthermore, EAPoIP MUST also support the initial EAPoIP
Request/Response Types that MUST be supported by PPP EAP. These
include the Request/Response Types "Identity", "Notification", "NAK"
and "MD5-Challenge" - with the corresponding code values 1, 2, 3,
and 4, respectively.
5 A simplified model of a "host-initiated" EAPoIP scheme
The following diagram shows a simplified model of the message
exchanges of an EAPoIP scheme where the host takes the initiative:
Roaming host Access Router/DHCP server PAA
| | |
| | |
| 1) PAA Discovery | |
|<----------------------- | |
| | |
....|.................................................|.......
| |
| 2a) Session Key Request |
|------------------------------------------------>|
| |
| | AAA
| |<----->TTP
| |
| 2b) Session Key Response |
|<------------------------------------------------|
| |
....|.................................................|.......
| |
| 3a) (Re-)authentication Challenge |
|<------------------------------------------------|
| |
| 3b) (Re-)authentication Response |
|------------------------------------------------>|
| |
....|.................................................|.......
| |
| 4a) (Re-)authentication Challenge |
|------------------------------------------------>|
| |
| 4b) (Re-)authentication Response |
|<------------------------------------------------|
| |
....|.................................................|.......
The PAA may be co-located with the Access Router or DHCP server.
The messages are described as follows:
1) PAA discovery:
P. Engelstad Expires July 2002 [Page 4]
EAP over IP February 2002
A roaming host discovers the IP-address (and identity) of a PAA
in an extension to a Router Advertisement or by means of DHCP. A
PAA Discovery mechanism is proposed in [1]. It allows the host to
discover the IP-address and identity of the PAA, as well as the
session key establishment method to be used in the subsequent
message exchange.
This scheme assumes that it is the host that sends the first message
after having discovered a PAA.
2) Session Key Distribution:
Assuming, for simplicity, that a session key establishment algorithm
uses only 2 local passes between host and PAA:
2a) The host initiates the Session Key Establishment phase (as an
EAP Authenticator) by sending an EAP Session Key Request to the
PAA.
2b) PAA acts as an EAP peer and sends an EAP Session Key
Response. PAA MAY use a back-end AAA infrastructure, a
Certificate Authority or another kind of Trusted Third Party
(TTP) to intercept and validate the Session Key Request and/or to
formulate the Session Key Response.
The Session Key Establishment phase may naturally use more message
passes.
If the host did not discover PAA's identity during the PAA Discovery
phase, it may initially send an Identity Request. (This Request may
alternatively trigger the PAA to initiate the Session Key
Establishment process going in the opposite direction, i.e. with PAA
acting as the EAP Authenticator.)
A PAA or host MAY re-authenticate the other party at any time, using
message exchange 3 or 4 (respectively) in the figure above.
It should be noted that some session key establishment algorithms do
not incorporate proof of freshness/liveliness of one or both
parties. If this is the case, the session key establishment
algorithm SHOULD be followed up by (re-) authentication.
3) PAA (re-) authenticates host
3a) PAA acts as an EAP authenticator and sends a challenge to the
host.
3b) The host responds to the challenge (e.g. by computing a MD-5
hash over the challenge), using the session key that was
established during the Session Key message exchange (above).
4) Host (re-) authenticates PAA
P. Engelstad Expires July 2002 [Page 5]
EAP over IP February 2002
As in 3 above, but the roles of host and PAA are reversed.
EAPoIP Success and Failure messages have been omitted for
simplicity.
6 A simplified model of a "network-initiated" EAPoIP scheme
The following diagram shows a simplified model of the message
exchanges of an EAPoIP scheme where the network takes the
initiative:
Roaming host Access Router/DHCP server PAA
| | |
| | |
| | 1)Some trigger |
| |---------------------->|
| | |
....|.................................................|.......
| |
| 2a) Identity Request |
|<------------------------------------------------|
| 2b) Identity Response |
|------------------------------------------------>|
| |
| 2c) Session Key Establishment | AAA
|<----------------------------------------------->|<----->TTP
| |
....|.................................................|.......
The PAA may be co-located with the Access Router or DHCP server.
This scheme assumes that the PAA receives some triggers indicating
arrival of a new host. PAA MAY for example be triggered by stateful
address configuration, e.g. the DHCP server signals to PAA that
there is a new host at the IP-address it has just handed out.
PAA will first reveal the identity of a host, by sending an EAPoIP
Identity Request, before continuing with the Session Key
Establishment.
7 Identity hiding
Some Session Key Establishment algorithms MAY help conceal the
host's identity. Identity hiding MAY alternatively be addressed by
other protocols, e.g. a host MAY use temporary user names and/or
temporary IP-addresses. The use of temporary IPv6 addresses is
specified in [5].
P. Engelstad Expires July 2002 [Page 6]
EAP over IP February 2002
8 Additional Security Requirements
Since PPP EAP makes assumptions about the characteristics of the
underlying point-to-point link, a PPP EAP method cannot blindly be
substituted with its EAPoIP counterpart without taking security
threats into account.
EAP methods that are vulnerable to attacks likely on multi-access
links (including eavesdropping, address spoofing, replay attacks and
man-in-the-middle attacks) MUST NOT be used with EAPoIP. EAPoIP may
instead pose additional requirements to existing EAP methods.
Furthermore, EAPoIP-specific methods that are designed for multi-
access environments MAY also be developed.
These issues should be addressed in follow-on documents.
9 Retransmission and timeout mechanisms
The EAPoIP protocol may require specific retransmission and timeout
mechanisms based the possibility of multi-access wireless subnets.
These mechanisms also depend on whether a user is expected to type
in a password with long latency and possibility of typos, or whether
a software or hardware module is expected to handle this part on
behalf of the user (i.e. user authentication versus device
authentication).
10 Security Considerations
An important issue is how to secure the EAPoIP protocol.
Authenticators and peers MAY validate their lower-layer identifiers,
such as IP- and MAC- addresses, in addition to their NAIs, during
either the initial session key establishment or during subsequent
(re-) authentication.
EAPoIP will then be better secured against address spoofing and man-
in-the-middle attacks. It also facilitates use of address filtering
as one (of possibly many) means to enforce network access control.
IANA Considerations
IANA-assigned port numbers need be assigned to EAPoIP.
Acknowledgements
...
References
P. Engelstad Expires July 2002 [Page 7]
EAP over IP February 2002
[1] Engelstad, P., "Discovery Mechanism for PANA Authentication
Agents (PAA-discovery)", <draft-engelstad-pana-paa-discovery-
00.txt>, January 2002, Work in Progress.
[2] Blunk, L. and Vollbrecht, J., "PPP Extensible Authentication
Protocol", RFC 2284, March 1998.
[3] Blunk, L., Vollbrecht, J., and Aboba, B., "Extensible
Authentication Protocol (EAP)", <draft-ietf-pppext-rfc2284bis-
01.txt> (RFC2284bis), November 2001, Work in Progress.
[4] Aboba, B., Beadles, M. "The Network Access Identifier", RFC 2486,
January 1999.
[5] Narten, T., and Draves, R., "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
Authors' Addresses
Paal E. Engelstad
Telenor R&D (California)
399 Sherman Ave. Suite #12
Palo Alto, CA 94306, USA
Tel.: + 1-650- 714 7537
e-mail: paal@telenorisv.com
P. Engelstad Expires July 2002 [Page 8]
