Internet Draft P. Engelstad
Telenor R&D
Expires July 2002 January 2002
A mechanism for Discovery of PANA Authentication Agents
(PAA-discovery)
<draft-engelstad-pana-paa-discovery-00.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
A PANA authentication protocol is under development in the PANA
Working Group. It will allow hosts to authenticate with PANA
Authentication Agents (PAAs). The protocol is expected to run over
some IP-based transport protocol, such as ICMP, UDP, TCP or SCTP.
Before a host can authenticate with a PAA, it must obtain an IP-
address of the PAA. This document specifies such a "discovery"
mechanism by defining extensions (or options) to Router
Advertisements and DHCP messages for both IPv4 and IPv6. Hosts MAY
also obtain an identity of a PAA and other information during the
discovery process. The proposed discovery mechanism makes no
assumptions about the location of a PAA, and more than one PAA may
be discovered.
P. Engelstad Expires July 2002 [Page 1]
EAP over IP January 2002
Table of Contents
1 Introduction.....................................................2
2 Terminology......................................................3
3 Extensions for PAA Discovery.....................................3
3.1 ICMPv4 Router Advertisement Extension for PAA Discovery......4
3.2 DHCPv4 Extension for PAA Discovery...........................4
3.3 ICMPv6 Router Advertisement Option for PAA Discovery.........5
3.4 DHCPv6 Option for PAA Discovery..............................5
3.5 Sub-options for PAA Discovery................................6
3.5.1 PAA IPv4 Address Sub-option............................6
3.5.2 PAA IPv6 Address Sub-option............................6
3.5.3 PAA Identity Sub-option................................7
3.5.4 PANA Initiation Sub-option.............................8
3.5.5 Other Sub-option.......................................8
4 Security Considerations..........................................9
IANA Considerations................................................9
Acknowledgements..................................................10
References........................................................10
Authors' Addresses................................................11
1 Introduction
A PANA authentication protocol is under development in the PANA
Working Group. It will allow hosts to authenticate with PANA
Authentication Agents (PAAs). The protocol is expected to run over
some IP-based transport protocol, such as ICMP, UDP, TCP or SCTP.
Before a host can authenticate with a PAA, it must obtain an IP-
address of the PAA. This document specifies such a "discovery"
mechanism by defining extensions (or options) to Router
Advertisements and DHCP messages for both IPv4 and IPv6. These
extensions (or options) are specified in Section 3 of this document.
In situations where DHCP is not implemented, PAA-discovery relies on
extensions to IPv4 and IPv6 Router Advertisements. However, such
extensions MAY consume substantial bandwidth on the access subnet.
Therefore, it is assumed that PAA-discovery should use DHCP
extensions instead in situations where DHCP is implemented. (In this
case the 'M'-bit or 'O' bit will be set in an IPv6 Router
Advertisement [5], and the Router Advertisement will not contain any
extensions for PAA-discovery.)
In addition to discovering IP-addresses of PAAs, hosts MAY also
obtain PAA Identifiers (e.g. in terms of Network Access Identifiers
[9]) and other relevant information during the discovery process.
Additional information MAY facilitate the subsequent authentication
process. However, the benefits of these enhancements to the
discovery mechanism may be ruled out by the bandwidth penalty that
extra information imposes on the access subnet.
P. Engelstad Expires July 2002 [Page 2]
EAP over IP January 2002
The proposed discovery mechanism makes no assumption about the
location of a PAA; it may be located on the Access Router or
somewhere else in the access domain. Moreover, more than one PAA may
be discovered. This flexibility assures that the discovery mechanism
probably will be able to support the final PANA authentication
protocol, when that specification is completed. Examples of PANA
protocol proposals can be found in [1], [11] and [12].
A host SHOULD acquire an IP-address for itself, prior to
authenticating with PAA. A good argument for this requirement is
that the access network cannot enforce IP-address assignment anyway:
A malicious host can easily configure any IP-address for itself,
although it may encounter problems if the access network implements
IP-address filtering (e.g. on the access router).
The mechanism proposed in this document allows the host to discover
IP-addresses of PAAs while acquiring an IP-address for itself, using
either stateless address auto-configuration or DHCP. A PAA discovery
mechanism for hosts that intend to authenticate without an IP-
address, is outside the scope of this document.
The host can actively initiate the discovery process by sending an
ICMP Router Solicitation or a DHCP request. The discovery mechanism
allows a host to discover IP-addresses of more than one PAA. If the
host cannot reach one PAA, it may try to get in contact with another
PAA of which it also has acquired an IP-address.
There are a number of reasons why a host may not be able to get in
contact with one of the PAAs of which it has acquired an IP-address:
The PAA or the host could, for example, be subject to a security
attack or an extension may have carried obsolate information about a
PAA that is no longer present in the access domain.
2 Terminology
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. 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 RFC 2119 [2].
3 Extensions for PAA Discovery
Router Advertisement Extensions and DHCP Extensions (or "Options")
are defined for both IPv4 and IPv6. Any of these extensions will
inform a host that acquires an IPv4 or IPv6 address on how to
initiate authentication with PAA. The extensions are intended to
simplify PAA discovery, but they are not mandatory.
P. Engelstad Expires July 2002 [Page 3]
EAP over IP January 2002
Each extension conveys information about one particular PAA. If
information about several PAAs needs to be conveyed to the host, the
Router Advertisement or DHCP reply message MAY include multiple
extensions, one for each PAA.
3.1 ICMPv4 Router Advertisement Extension for PAA Discovery
The following extension is suggested for use with ICMPv4 [3]:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-options...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
PANA-RAv4-EXTENSION (TBD)
Length
This value equals the number of octets of this extension,
excluding the Type and Length fields, i.e. only the length of the
sub-option field.
Sub-options
Sub-options are specified in section 3.5.
3.2 DHCPv4 Extension for PAA Discovery
The following extension is suggested for use with DHCPv4 [4]:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Len | Sub-options...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
PANA-DHCPv4-EXTENSION (TBD)
Len
This value equals the number of octets of this extension,
excluding the Code and Len fields, i.e. only the length of the
sub-option field.
Sub-options
P. Engelstad Expires July 2002 [Page 4]
EAP over IP January 2002
Sub-options are specified in section 3.5.
3.3 ICMPv6 Router Advertisement Option for PAA Discovery
The following option is suggested for use with ICMPv6 [5]:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-options...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
PANA-RAv6-OPTION (TBD)
Length
This value equals the number of octets of this option, excluding
the Type and Length fields, i.e. only the length of the sub-
option field.
Sub-options
Sub-options are specified in section 3.5.
3.4 DHCPv6 Option for PAA Discovery
The following option is suggested for use with DHCPv6 [6]:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option code | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Option ...
+-+-+-+-+-+-+-+
option code
PANA-DHCPv6-OPTION (TBD)
option length
This value equals the number of octets of this option, excluding
the option code and option-length fields, i.e. only the length of
the sub-option field.
Sub-options
P. Engelstad Expires July 2002 [Page 5]
EAP over IP January 2002
Sub-options are specified in section 3.5.
3.5 Sub-options for PAA Discovery
3.5.1 PAA IPv4 Address Sub-option
This sub-option provides the host with the IPv4 address of a PAA. It
is typically appended to a DHCPv4 Extension or an IPv4 Router
Advertisement Extension for PAA Discovery.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-opt. Type | Length | IPv4 Address (4 octets)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Option Type
TBD
Length
4
IPv4 Address
An IPv4 address of the PAA referred to in this extension.
3.5.2 PAA IPv6 Address Sub-option
This sub-option provides the host with the IPv6 address of a PAA. It
is typically appended to a DHCPv6 Option or an IPv6 Router
Advertisement Option for PAA Discovery.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-opt. Type | Length | IPv6 Address (16 octets)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-option Type
TBD
Length
16
IPv6 Address
P. Engelstad Expires July 2002 [Page 6]
EAP over IP January 2002
An IPv6 address of the PAA referred to in this extension.
For the time being, there are unsolved problems associated with
using shared addresses for stateful communication (as described
in RFC 1546 [7]). Since the PANA protocol will be required to
accommodate re-authentication, PAA will be a stateful agent.
Thus, an IPv6 anycast (or multicast) address SHOULD NOT be used
in this sub-option, before resolution of these problems.
In the future, one may pre-assign to PAA site-scoped IPv6 addresses
that can be hard-coded into the host. (E.g. the range of five site-
scoped addresses fec0:0:0:ffff::4 - fec0:0:0:ffff::8 from the
address space with SLA value of 'ffff' could be assigned to PAAs in
access domains. It is similar to what is proposed for stateless IPv6
DNS discovery in [8]). This may facilitate the authentication
process, reduce the fate sharing, and save the additional bandwidth
of conveying PAA addresses to the host.
3.5.3 PAA Identity Sub-option
This sub-option may facilitate the authentication process by
allowing a roaming host to discover an identity of a PAA.
Thus, the host can easily determine the (re-) authentication
procedure due to the type of handover - e.g. if it has:
(1) roamed to a new access domain;
(2) roamed to a subnet of the same access domain, but under a
different PAA; or
(3) roamed to a subnet under the same PAA.
Furthermore, if the PANA protocol incorporates EAP the host MAY also
authenticate the PAA directly without sending an initial EAP
Identity request first.
Note, however, that the additional bandwidth consumption on the
access link MAY rule out the benefits of this sub-option.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-opt. Type | Length | PAA Identity ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-option Type
TBD
Length
P. Engelstad Expires July 2002 [Page 7]
EAP over IP January 2002
Length of the PAA Identity field.
PAA Identity
The identity of the PAA. This identity SHOULD be represented in
terms of a Network Access Identifier (NAI), as specified in [9].
3.5.4 PANA Initiation Sub-option
This sub-option informs the host on how to proceed with the PANA
authentication process, after the PAA discovery process.
It is likely that the roaming host is the one that should take the
initial step in the PANA protocol after having completed PAA-
discovery. If this is the case, the PANA Initiation Code in this
sub-option gives the host directions on how to go on.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-opt. Type | Length | PANA Initiation Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-option Type
TBD
Length
2
PANA Initiation Code
A code which informs hosts on how to proceed with the PANA
protocol, after having discovered a PAA.
It is likely that the PANA protocol be carried by messages with EAP
format, and that the host will initiate the communication using a
specific Request/Response Type. The PANA Initiation Code values in
the range of 0 - 255 may therefore be reserved for EAP
Request/Response Types.
3.5.5 Other Sub-option
Other sub-options may be specified in follow-on documents.
The final PANA protocol MAY for example find it useful to define a
sub-option that allows hosts to obtain temporary MD-5 challenges
from the access network during the discovery process.
P. Engelstad Expires July 2002 [Page 8]
EAP over IP January 2002
4 Security Considerations
A malicious node MAY send to a host a Router Advertisement
containing a valid PAA-discovery sub-option, although other
information in the advertisement MAY be spoofed. Thus, a malicious
node can easily become an intruder-in-the-middle that gets access to
the domain by using the host as an oracle when authenticating with
PAA. This is particularly easy when access control is based only on
address filtering of userÆs data traffic without employing security
gateways in the access domain.
To allow for packet filtering as a means to enforce access control,
the PANA protocol MUST let a PAA confirm to hosts that information
related to the access domain (including Access Router addresses) are
correct. Furthermore, the PANA protocol MUST let a host confirm to
PAAs that the hostÆs IP-addresses and other information related to
the host (e.g. L2-addresses, port numbers etc.) are correct.
Although an Authentication Sub-Option MAY be able to address this
issue during the PAA-discovery phase of the PANA protocol, it is
assumed that it will be better addressed by other parts of the PANA
protocol:
a) Hosts and PAAs MAY validate each otherÆs network access
information during the session key establishment phase of the
PANA protocol. (Then, the session key MUST be re-established
every time a host changes address or roams to a new access
router.)
b) Alternatively, the PANA protocol MAY allow an authenticator to
validate network access information of peers during the (re-)
authentication phase of the PANA protocol. (In this case, the
session key establishment phase MUST be followed up by (re-)
authentication.)
c) Both a) and b)
There are other unresolved security issues related to Neighbor
Discovery. An overview is provided in [10]. Since such threats are
not only specific to the PANA protocol, they are outside the scope
of the PANA Working Group. They are also outside the scope of this
document.
IANA Considerations
An ICMPv4 Router Advertisement Extension Type value need be assigned
for PAA Discovery. (Please refer to the PANA-RAv4-EXTENSION value in
sub-section 3.1.)
A DHCPv4 Extension Code value need be assigned for PAA Discovery.
(Please refer to the PANA-DHCPv4-EXTENSION value in sub-section
3.2.)
P. Engelstad Expires July 2002 [Page 9]
EAP over IP January 2002
AN ICMPv6 Router Advertisement Option Type value need be assigned
for PAA Discovery. (Please refer to the PANA-ICMPv6-EXTENSION value
in sub-section 3.3.)
A DHCPv6 Option Code value need be assigned for PAA Discovery.
(Please refer to the PANA-DHCPv6-OPTION value in sub-section 3.4.)
Sub-option type values need be assigned to sub-options presented in
sub-section 3.5.
Acknowledgements
...
References
[1] Tsirtis, G., "EAP over ICMP", <draft-tsirtsis-eap-over-icmp-
00.txt>, Work in progress, January 2002.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[3] Deering, S. "ICMP Router Discovery Messages", RFC 1256,
September 1991.
[4] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[5] Narten, T., Nordmark, E., Simpson, W. "Neighbor Discovery for
IP Version 6", RFC 2461, December 1998.
[6] Droms, R. (ed.), "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", Work in progress, November 2001.
[7] Partridge, C., Mendez, T. and Milliken, W., "Host Anycasting
Service", RFC 1546, November 1993.
[8] Thaler, D., Hagino, J.I., "IPv6 Stateless DNS Discovery", Work
in progress, November 2001.
[9] Aboba, B., Beadles, M. "The Network Access Identifier", RFC
2486, January 1999.
[10] Kempf, J., Nordmark, E. "Threat Analysis for IPv6 Public
Multi-Access Links", <draft-kempf-ipng-netaccess-threats-00.txt>,
Work in progress.
[11] Engelstad, P. "Extensible Authentication Protocol over IP
(EAPoIP)", <draft-engelstad-pana-eap-over-ip-01.txt>, Work in
progress.
P. Engelstad Expires July 2002 [Page 10]
EAP over IP January 2002
[12] Yegin et al., "Secure Network Access Using Router Discovery
and AAA", <draft-yegin-unap-snard-00.txt>, Work in progress.
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 11]