One document matched: draft-ietf-pana-preauth-09.xml
<?xml version='1.0'?>
<?xml-stylesheet type='text/xsl'
href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
<!ENTITY eap-keying PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-eap-keying.xml'>
<!ENTITY pana-mobopts PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pana-mobopts.xml'>
<!ENTITY pana-cxtp PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pana-cxtp.xml'>
<!ENTITY hokey-preauth-ps PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hokey-preauth-ps.xml'>
<!ENTITY pana-iana PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.arkko-pana-iana.xml'>
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2828 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2828.xml'>
<!ENTITY rfc2865 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml'>
<!ENTITY rfc3588 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml'>
<!ENTITY rfc3748 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml'>
<!ENTITY rfc4067 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4067.xml'>
<!ENTITY rfc5191 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5191.xml'>
] >
<?rfc iprnotified="yes" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc inline="no"?>
<rfc ipr='trust200811' category='exp' docName='draft-ietf-pana-preauth-09'>
<front>
<title abbrev="Pre-authentication Support for PANA">
Pre-authentication Support for PANA
</title>
<author initials="Y." surname="Ohba"
fullname="Yoshihiro Ohba">
<organization abbrev="Toshiba">
Toshiba Corporate Research and Development Center
</organization>
<address>
<postal>
<street>1 Komukai-Toshiba-cho</street>
<city>Saiwai-ku, Kawasaki</city>
<region>Kanagawa</region>
<code>212-8582</code>
<country>Japan</country>
</postal>
<phone>+81 44 549 2230</phone>
<email>yoshihiro.ohba@toshiba.co.jp</email>
</address>
</author>
<author initials="A." surname="Yegin"
fullname="Alper Yegin">
<organization abbrev="Samsung">
Samsung
</organization>
<address>
<postal>
<city>Istanbul</city>
<country>Turkey</country>
</postal>
<email>alper.yegin@yegin.org</email>
</address>
</author>
<date month="February" year="2010"/>
<workgroup>PANA Working Group </workgroup>
<abstract>
<t>
This document defines an extension to the Protocol for
carrying Authentication for Network Access (PANA) for
proactively establishing a PANA security association between a
PANA client in one access network and a PANA authentication
agent in another access network to which the PANA client may
move.
</t>
</abstract>
</front>
<middle>
<section title='Introduction'>
<t>
The Protocol for carrying Authentication for Network Access
(PANA) <xref target='RFC5191'/> carries EAP messages between a
PaC (PANA Client) and a PAA (PANA Authentication Agent) in the
access network. If the PaC is a mobile device and is capable
of moving from one access network to another while running its
applications, it is critical for the PaC to perform a handover
seamlessly without degrading the performance of the
applications during the handover period. When the handover
requires the PaC to establish a PANA session with the PAA in
the new access network, the signaling to establish the PANA
session should be completed as fast as possible. See <xref
target='I-D.ietf-hokey-preauth-ps'/> for the handover latency
requirements.
</t>
<t>
This document defines an extension to the PANA protocol <xref
target='RFC5191'/> used for proactively executing EAP
authentication and establishing a PANA SA (Security
Association) between a PaC in an access network and a PAA in
another access network to which the PaC may move. The
extension to the PANA protocol is designed to realize direct
pre-authentication defined in <xref
target='I-D.ietf-hokey-preauth-ps'/>. How to realize
authorization and accounting with the use of the
pre-authentication extension is out of the scope of this
document.
</t>
<section title="Specification of Requirements">
<t>
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 <xref target='RFC2119'/>.
</t>
</section>
</section>
<section title='Terminology'>
<t>
The following terms are used in this document in addition to
the terms defined in <xref target='RFC5191'/>.
</t>
<list style='hanging'>
<t hangText='Serving Network:'>
The access network to which the host is currently attached.
</t>
<t hangText='Candidate Network:'>
An access network that is a potential target of host's
handover.
</t>
<t hangText='Serving PAA (SPAA):'>
A PAA that resides in the serving network and provides
network access authentication for a particular PaC.
</t>
<t hangText='Candidate PAA (CPAA):'>
A PAA that resides in a candidate network to which the
PaC may move. A CPAA for a particular PaC may be a SPAA
for another PaC.
</t>
<t hangText='Pre-authentication:'>
Pre-authentication refers to EAP pre-authentication and
defined as the utilization of EAP to pre-establish EAP
keying material on an authenticator prior to arrival of the
peer at the access network served by that authenticator
<xref target='I-D.ietf-hokey-preauth-ps'/>. In this draft,
EAP pre-authentication is performed between a PaC and a
CPAA.
</t>
</list>
</section>
<section anchor='section-pre-authentication'
title='Pre-authentication Procedure'>
<t>
A PaC that supports pre-authentication may establish a PANA
session for each CPAA.
</t>
<t>
There may be several mechanisms for a PaC to discover a CPAA.
An IP address of the discovered CPAA is the output of those
mechanisms. PANA pre-authentication is performed between the
PaC and CPAA using the discovered IP address of the CPAA.
IEEE 802.21 <xref target='802.21'/> Information Service MAY be
used as a CPAA discovery mechanism.
</t>
<t>
There may be a number of criteria for CPAA selection, the
timing to start pre-authentication and the timing as to when
the CPAA becomes the SPAA. Such criteria can be
implementation specific and thus are outside the scope of this
document.
</t>
<t>
Pre-authentication is initiated by a PaC in a similar way as
normal authentication. A new 'E' (prE-authentication) bit is
defined in the PANA header. When pre-authentication is
performed, the 'E' (prE-authentication) bit of PANA messages
is set in order to indicate that this PANA run is for
pre-authentication. Use of pre-authentication is negotiated
as follows.
</t>
<t>
<list style='symbols'>
<t>
When a PaC initiates pre-authentication, it sends a
PANA-Client-Initiation (PCI) message with the 'E'
(prE-authentication) bit set. The CPAA responds with a
PANA-Auth-Request (PAR) message with the 'S' (Start) and
'E' (prE-authentication) bits set only if it supports
pre-authentication. Otherwise, the 'E'
(prE-authentication) bit of the PAR message will be
cleared according to Section 6.2 of <xref
target='RFC5191'/>, which results in a negotiation
failure.
</t>
<t>
Once the PaC and CPAA have successfully negotiated on
performing pre-authentication using the 'S' (Start) and
'E' (prE-authentication) bits, the subsequent PANA
messages exchanged between them MUST have the 'E'
(prE-authentication) bit set until CPAA becomes SPAA of
the PaC. The PaC may conduct this exchange with more than
one CPAA. If the PaC and CPAA have failed to negotiate on
performing pre-authentication, the PaC or CPAA that sent a
message with both the 'S' (Start) and 'E'
(prE-authentication) bits set MUST discard the message
received from the peer with 'S' (Start) bit set and the
'E' (prE-authentication) bit cleared, which will
eventually result in PANA session termination.
</t>
</list>
</t>
<t>
If IP reconfiguration is needed in the access network
associated with the CPAA, the 'I' (IP Reconfiguration) bit in
PAR messages used for pre-authentication between the PaC and
CPAA is also set. The 'I' (IP Reconfiguration) bit in these
messages takes effect only after the CPAA becomes the SPAA.
</t>
<t>
When a CPAA of the PaC becomes the SPAA due to, e.g., movement
of the PaC, the PaC informs the PAA of the change using
PANA-Notification-Request (PNR) and PANA-Notification-Answer
(PNA) messages with the 'P' (Ping) bit set and the 'E'
(prE-authentication) bit cleared. The 'E'
(prE-authentication) bit MUST be cleared in subsequent PANA
messages.
</t>
<t>
A PANA SA is required for pre-authentication in order to
securely associate the PNR/PNA exchange to the earlier
authentication.
</t>
<t>
The PANA session between the PaC and a CPAA is deleted by
entering the termination phase of the PANA protocol.
</t>
<t>
Example call flows for pre-authentication is shown in <xref
target='figure-call-flow'/>. Note that EAP
authentication is performed over PAR and PAN exchanges.
</t>
<figure anchor='figure-call-flow'
title='Pre-authentication Call Flow'>
<artwork xml:space="preserve"><![CDATA[
PaC CPAA
| |
+------------------+ |
|Pre-authentication| |
|trigger | |
+------------------+ |
| PCI w/'E' bit set |
|------------------------------------------------>|
| PAR w/'S' and 'E' bits set |
|<------------------------------------------------|
| PAN w/'S' and 'E' bits set |
|------------------------------------------------>|
| PAR-PAN exchange w/'E' bit set |
|<----------------------------------------------->|
| PAR w/'C' and 'E' bits set |
|<------------------------------------------------|
| PAN w/'C' and 'E' bits set |
|------------------------------------------------>|
. . .
. . .
+----------+ |
| Movement | |
+----------+ |
| PNR w/ 'P' bit set and w/o 'E' bit set |
|------------------------------------------------>|
| +-----------------+
| |CPAA becomes SPAA|
| +-----------------+
| PNA w/ 'P' bit set and w/o 'E' bit set |
|<------------------------------------------------|
| |
]]>
</artwork>
</figure>
</section>
<section anchor='section-pana-extensions' title='PANA Extensions'>
<t>
A new 'E' (prE-authentication) bit is defined in Flags field
of PANA header as follows.
<artwork>
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R S C A P I E r r r r r r r r r|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
<list style='hanging'>
<t hangText='E(PrE-authentication)'>
When pre-authentication is performed, the 'E'
(prE-authentication) bit of PANA messages is set in
order to indicate whether this PANA run is for
pre-authentication. The exact usage of this bit is
described in <xref
target='section-pre-authentication'/>. This bit is to
be assigned by IANA.
</t>
</list>
</t>
</section>
<section anchor='section-backward-compatibility'
title='Backward Compatibility'>
<t>
Backward compatibility between a PANA entity that does not
support the pre-authentication extension and another PANA
entity that supports the pre-authentication extension is
maintained as follows.
</t>
<t>
When a PaC that supports the pre-authentication extension
initiates PANA pre-authentication by sending a PCI message
with the 'E' (prE-authentication) bit set to a PAA that does
not support the pre-authentication extension, the PAA will
ignore the E-bit according to Section 6.2 of <xref
target='RFC5191'/>, and try to process the message as a
normal authentication attempt. As a result, the PaC will
receive a PAR message with the 'E' (prE-authentication) bit
cleared. In this case, the negotiation on the use of
pre-authentication will fail and eventually the PANA session
will be terminated as described in Section <xref
target='section-pre-authentication'/>.
</t>
</section>
<section title='Security Considerations'>
<t>
This specification is based on the PANA protocol and it exhibits
the same security properties, except for one important
difference: Pre- authenticating PaCs are not physically
connected to an access network associated with the PAA, but they
are connected to some other network somewhere else on the
Internet. This distinction can create greater DoS vulnerability
for systems using PANA pre-authentication if appropriate
measures are not taken. An unprotected PAA can be forced to
create state by an attacker PaC which merely sends PCI messages.
</t>
<t>
<xref target='RFC5191'/> describes how PAA can stay stateless
while responding to incoming PCIs. PAAs using
pre-authentication SHOULD be following those guidelines (see
<xref target='RFC5191'/> Section 4.1).
</t>
<t>
Furthermore, it is recommended that PANA pre-authentication
messages are only accepted from PaCs originating from well-known
IP networks (e.g., physically adjacent networks) for a given
PAA. These IP networks can be used with a white-list implemented
either on the firewall protecting the perimeter around the PAA,
or on the PAA itself. This prevention measure SHOULD be used
whenever it can be practically applied to a given deployment.
</t>
</section>
<section title='IANA Considerations'>
<t>
As described in <xref target='section-pana-extensions'/> and
following the new IANA allocation policy on PANA message <xref
target='I-D.arkko-pana-iana'/>, bit 6 of the Flags field of
the PANA Header needs to be assigned by IANA for the 'E'
(prE-authentication) bit.
</t>
</section>
<section title='Acknowledgments'>
<t>
The author would like to thank Basavaraj Patil, Ashutosh
Dutta, Julien Bournelle, Sasikanth Bharadwaj, Subir Das, Rafa
Marin Lopez, Lionel Morand, Victor Fajardo, Glen Zorn, Qin Wu,
Jari Arrko, Pasi Eronen and Joseph Salowey for their support
and valuable feedback.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc5191; &pana-iana;
</references>
<references title='Informative References'>
&rfc2119; &hokey-preauth-ps;
<reference anchor='802.21'>
<front>
<title>
Standard for Local and Metropolitan Area Networks:
Media Independent Handover Services
</title>
<author>
<organization>
IEEE
</organization>
</author>
</front>
<seriesInfo name="LAN MAN Standards Committee of the IEEE
Computer Society 802.21" value="2008" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:36:59 |