draft-ietf-pana-preauth-01.txt   draft-ietf-pana-preauth-02.txt 
PANA Working Group Y. Ohba PANA Working Group Y. Ohba
Internet-Draft Toshiba Internet-Draft Toshiba
Expires: September 4, 2006 March 3, 2006 Expires: May 21, 2008 November 18, 2007
Pre-authentication Support for PANA Pre-authentication Support for PANA
draft-ietf-pana-preauth-01 draft-ietf-pana-preauth-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 4, 2006. This Internet-Draft will expire on May 21, 2008.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document defines an extension to the PANA protocol used for This document defines an extension to the PANA protocol used for
proactively establishing a PANA SA (Security Association) between a proactively establishing a PANA SA (Security Association) between a
PaC in an access network and a PAA in another access network to which PaC in an access network and a PAA in another access network to which
the PaC may move. The proposed method operates across multiple the PaC may move. The proposed method operates across multiple
administrative domains. administrative domains.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . . 3 1.1. Specification of Requirements . . . . . . . . . . . . . . 3
2. Terminogy . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminogy . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Pre-authentication Procedure . . . . . . . . . . . . . . . . . 7 3. Pre-authentication Procedure . . . . . . . . . . . . . . . . . 4
4. PANA Extensions . . . . . . . . . . . . . . . . . . . . . . . 11 4. PANA Extensions . . . . . . . . . . . . . . . . . . . . . . . 7
5. Authorization and Accounting Considerations . . . . . . . . . 12 5. Authorization and Accounting Considerations . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 10
1. Introduction 1. Introduction
The PANA protocol [I-D.ietf-pana-pana] carries EAP messages between a The PANA protocol [I-D.ietf-pana-pana] carries EAP messages between a
PaC (PANA Client) and a PAA (PANA Authentication Agent) in the access 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 one network. If the PaC is a mobile device and is capable of moving one
access network to another while running its applications, it is access network to another while running its applications, it is
critical for the PaC to perform a handover seamlessly without critical for the PaC to perform a handover seamlessly without
degrading the performance of the applications during the handover degrading the performance of the applications during the handover
period. When the handover requires the PaC to establish a PANA period. When the handover requires the PaC to establish a PANA
session with the PAA in the new access network, the signaling to session with the PAA in the new access network, the signaling to
establish the PANA session should be completed as fast as possible. establish the PANA session should be completed as fast as possible.
There is an optimization method based on Context Transfer Protocol This document defines an extension to the PANA protocol
(CTP) [RFC4067] to reduce the signaling delay for establishing a PANA [I-D.ietf-pana-pana] used for proactively executing EAP
session with a new PAA upon a handover [I-D.ietf-pana-mobopts][I- authentication and establishing a PANA SA (Security Association)
D.ietf-pana-cxtp]. between a PaC in an access network and a PAA in another access
network to which the PaC may move. The proposed method operates
The CTP-based method have the following issues. First, it is not across multiple AAA domains. The extension to the PANA protocol is
readily applicable to handovers across multiple administrative designed to realize direct pre-authentication defined in
domains since having a security association between PAAs in different [I-D.ietf-hokey-preauth-ps].
administrative domains is practically difficult. Second, even within
a single administrative domain, the CTP-based method is difficult to
work when the previous and new access networks have different
authorization characteristics, e.g., on use of NAP and ISP separate
authentication. Third, the CTP-based method relies on deriving the
PANA_MAC_Key used between the PaC and the PAA in the new access
network from the AAA-Key used between the PaC and the PAA in the
previous access network, which does not provide perfect cryptographic
separation between the PAAs.
To address the issues on the CTP-based method, this document defines
an extension to the PANA protocol [I-D.ietf-pana-pana] 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 proposed
method operates across multiple administrative domains.
Although the proposed method covers the case that is also covered by
the CTP-based method (i.e., homogeneous authorization characteristics
in a single administrative domain), the purpose of this document is
not to replace the CTP-based method. Instead, the purpose of this
document is to provide a way to cover the cases that are not covered
by the other method. For the case covered by the CTP-based method,
the CTP-based method may be used.
1.1. Specification of Requirements 1.1. Specification of Requirements
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in [RFC2119]. are to be interpreted as described in [RFC2119].
2. Terminogy 2. Terminogy
The following terms are used in this document in addition to the The following terms are used in this document in addition to the
terms defined in [I-D.ietf-pana-pana]. terms defined in [I-D.ietf-pana-pana].
Access Network: Serving PAA (SPAA): A PAA that resides in the serving network and
provides network access authentication for a particular PaC. For
A network through which a PaC can access to the Internet via one simplicity, this document assumes that there is only one SPAA in
or more EPs controlled by one or more PAAs. An access network may the serving network while the pre-authentication mechanism
consist of multiple IP links. described in this document is generally applicable to the case
where there are two or more SPAAs in the serving network.
Local PAA:
A PAA that resides in the access network where the PaC is
connected. The term "local" is relative to the location of a
particular PaC.
Remote PAA:
A PAA that is not a local PAA for the PaC. The term "remote" is
relative to the location of a particular PaC. A PAA that is a
remote PAA for one PaC may be a local PAA for another PaC.
Local PaC:
A PaC that resides in the same access network as a particular PAA.
The term "local" is relative to the location of a specific PaC.
Remote PaC:
A PaC that is not a local PaC for a particular PAA. The term
"remote" is relative to the location of a particular PAA. A PaC
that is a remote PaC for one PAA may be a local PaC for another
PAA.
Active PAA:
A local PAA for which the PaC has a PANA session.
Preparing PAA:
A remote PAA which performs pre-authentication with the PaC. A
PAA that is serving as a preparing PAA for one PaC may be serving
as an active PAA for another PaC.
Pre-authentication:
Authentication performed between the PaC and a preparing PAA.
Pre-authentication SA:
A PANA SA that is established between the PaC and a preparing PAA
as a result of successful pre-authentication.
Active SA: 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.
A PANA SA that is established between the PaC and an active PAA. 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
[I-D.ietf-hokey-preauth-ps]. In this draft, EAP pre-
authentication is performed between a PaC and a CPAA.
Pre-authorization: Pre-authorization: An authorization for a PaC, made by a CPAA for
the PaC at the time of pre-authentication.
An authorization that is made for the PaC by a preparing PAA as a Post-authorization: An authorization for a PaC, made by a CPAA for
result of successful pre-authentication. the PaC when the CPAA becomes the SPAA for the PaC.
Post-authorization: Pre-authorization SA: A PANA SA established between a PaC and its
CPAA.
An authorization that was made for the PaC by a PAA that was Post-authorization SA: A PANA SA established between the PaC and its
acting as a preparing PAA and has become the active PAA. SPAA.
3. Pre-authentication Procedure 3. Pre-authentication Procedure
A PaC that supports pre-authentication may have one or more PANA A PaC that supports pre-authentication may establish a PANA session
sessions for preparing PAAs in addition to the PANA session for one for each CPAA.
of local PAAs.
There may be a number of ways to discover a remote PAA, however,
remote PAA discovery and remote PaC discovery is out of the scope of
this proposal.
There may be a number of criteria as to when and with which remote There may be several mechanisms for a PaC and a CPAA to discover each
PAA pre-authentication is performed. Such criteria can be other. However, such mechanisms are out of the scope of this
implementation specific and thus are outside the scope of this
document. document.
Pre-authentication may be initiated by both a PaC and a preparing There may be a number of criteria for CPAA selection, the timing to
PAA. A new flag P-flag is defined in the PANA header. When pre- start pre-authentication and the timing to make a pre-authorization
authentication is performed, the P-flag of PANA messages are set in SA a post-authorization SA (and hence the CPAA becomes the SPAA).
order to indicate whether this PANA run is for establishing a pre- Such criteria can be implementation specific and thus are outside the
authentication SA. Pre-authentication is negotiated in the PANA scope of this document.
discovery and handshake phase as follows.
o When a PaC initiates pre-authentication, it sends a PANA-PAA-
Discover message with the P-flag set. The PANA-PAA-Discover
message MUST be unicast. The PAA responds with a PANA-Start-
Request message with the P-flag set only when it supports pre-
authentication. Otherwise, it MUST silently discard the message.
o When a preparing PAA initiates pre-authentication, it sends a
PANA-Start-Request message with the P-flag set. The PaC responds
with a PANA-Start-Answer message with the P-flag set only when it
supports pre-authentication. Otherwise, it MUST silently discard
the message.
o Once the PaC and preparing PAA have agreed on performing pre- Pre-authentication may be initiated by both a PaC and a CPAA. A new
authentication during the discovery and handshake phase, the 'E' (prE-authentication) bit is defined in the PANA header. When
subsequent PANA messages exchanged between them MUST have the pre-authentication is performed, the 'E' (prE-authentication) bit of
P-flag set. PANA messages are set in order to indicate whether this PANA run is
for pre-authentication. Use of pre-authentication is negotiated as
follows.
When the preparing PAA becomes an active PAA due to movement of the o When a PaC initiates pre-authentication, it sends a PANA-Client-
PaC, the PaC performs an IP address update procedure using PANA- Initiation (PCI) message with the 'E' (prE-authentication) bit
Update exchange in order to update the PAA with the PaC's new address set. The PCI message MUST be unicast. The CPAA responds with a
obtained from the remote network where the PAA resides. The PANA-Start-Request (PSR) message with the 'S' (Start) and 'E'
completion of the PANA-Update procedure will change the pre- (prE-authentication) bits set only if it supports pre-
authentication SA to the active SA. The P-flag is not set in the authentication. Otherwise, it MUST silently discard the message.
PANA-Update messages and subsequent PANA messages.
When the PaC having an active SA with an active PAA as well as a pre- o When a CPAA initiates pre-authentication, it sends a PSR message
authentication SA with a preparing PAA changes its active PAA but with the 'S' (Start) and 'E' (prE-authentication) bits set. The
without changing the preparing PAA, the PaC performs an IP address PaC responds with a PANA-Start-Answer (PSA) message with the 'S'
update procedure using PANA-Update exchange in order to update the (Start) and 'E' (prE-authentication) bits set only if it supports
PAA of the PaC's new address obtained from the remote network where pre-authentication. Otherwise, it MUST silently discard the
the new active PAA resides. The completion of the PANA-Update message.
procedure will not change the pre-authentication SA to the active SA.
The P-flag is set in the PANA-Update messages and subsequent PANA
messages.
The pre-authentication SA and corresponding PANA session between the o Once the PaC and CPAA have agreed on performing pre-authentication
PaC and the pre-authenticated PAA can be deleted by entering the using the 'S' (Start) and 'E' (prE-authentication) bits, the
termination phase of the PANA protocol and performing the required subsequent PANA messages exchanged between them MUST have the 'E'
procedure for that phase. (prE-authentication) bit set.
An example call flow for PaC-initiated pre-authentication is shown in When a CPAA with which the PaC has a pre-authorization SA becomes the
Figure 1. SPAA due to, e.g., movement of the PaC, the PaC performs an IP
address update procedure defined in Section 5.6 of
[I-D.ietf-pana-pana] in order to update the SPAA with the PaC's new
address obtained from the new serving network. PANA-Notification-
Request (PNR) and PANA-Notification-Answer (PNA) messages with 'P'
(Ping) bit set are used for this purpose. The completion of the IP
address update procedure will change the pre-authorization SA to a
post-authorization SA. In this case, the 'E' MUST NOT be set in the
PNR and PNA messages and subsequent PANA messages.
A PaC in an access network establishes a PANA session with a local If there is another CPAA with which the PaC has a pre-authorization
PAA (l-PAA). At some point, it receives a trigger for pre- SA and the PaC wants to keep the pre-authorization SA after the
authenticating to a remote PAA (r-PAA) in another access network. change of SPAA, the PaC also performs an IP address update procedure
The PaC then initiates a pre-authentication procedure by sending a defined in Section 5.6 of [I-D.ietf-pana-pana] in order to update the
PANA-PAA-Discover message with the P-bit set. PANA messages are CPAA with the PaC's new address. PNR and PNA messages with 'P'
exchanged between the PaC and r-PAA, with the P-bit set for all (Ping) bit set is used for this purpose. In this case, the 'E' (prE-
messages. On successful completion of the PANA exchanges for pre- authentication) bit MUST be set in the PNR and PNA messages and
authentication and pre-authorization, a pre-authentication SA will be subsequent PANA messages. The IP address update procedure with the
established between the PaC and l-PAA. On the other hand, the active CPAA will not change the pre-authorization SA to a post-authorization
SA established between the PaC and l-PAA stays active. SA.
At some point after establishing the pre-authentication SA, the PaC The pre-authorization SA and the corresponding PANA session between
moves to the access network of the r-PAA. The r-PAA may be found by the PaC and a CPAA is deleted by entering the termination phase of
running PAA discovery over a newly created session or immediately the PANA protocol.
when the PaC attaches a link-layer device that is acting as an EP
whose device identifier was contained in the list of EP device
identifiers advertised by the r-PAA in the pre-authentication
procedure. If the r-PAA is found, the PaC initiates a PANA-Update
exchange over the session in which the pre-authentication SA has been
maintained to inform the PAA of the IP address change. In this PANA-
Update exchange, the P-bit is unset. On successful completion of the
PANA-Update exchange and post-authorization procedure, the pre-
authentication SA becomes the active SA. The active SA between the
PaC and l-PAA may stay active for a while to deal with the case in
which the PaC immediately switches back to the previous access
network.
If no such an r-PAA is found but other PAA(s) in the new access Example call flows for PaC-initiated pre-authentication and PAA-
network, a full PANA authentication or PANA mobility optimization may initiated pre-authentication are shown in Figure 1 and Figure 1,
be performed between the PaC and one of those PAA(s) based on the respectively.
procedures described in [I-D.ietf-pana-pana] and [I-D.ietf-pana-
cxtp].
PaC l-PAA r-PAA PaC CPAA
| | | | |
| PANA w/o P-bit set | | +------------------+ |
|<---------------------->| | |Pre-authentication| |
| | | |trigger | |
. . . +------------------+ |
. . . | PCI w/'E' bit set |
+------------------+ | |
|Pre-authentication| | |
|trigger | | |
+------------------+ | |
| PDI w/P-bit set |
|------------------------------------------------>| |------------------------------------------------>|
| PSR w/P-bit set | | PAR w/'S' and 'E' bits set |
|<------------------------------------------------| |<------------------------------------------------|
| PSA w/P-bit set | | PAN w/'S' and 'E' bits set |
|------------------------------------------------>| |------------------------------------------------>|
| PAR-PAN exchange w/P-bit set | | PAR-PAN exchange w/'E' bit set |
|<----------------------------------------------->|
| | +------------------+
| | |pre-authorization |
| | +------------------+
| PBR-PBA exchange w/P-bit set |
|<----------------------------------------------->| |<----------------------------------------------->|
| +------------------+
| |pre-authorization |
| +------------------+
| PAR w/'C' and 'E' bits set |
|<------------------------------------------------|
| PAN w/'C' and 'E' bits set |
|------------------------------------------------>|
. . . . . .
. . . . . .
+----------+ | | +----------+ |
| Movement | | | | Movement | |
+----------+ | | +----------+ |
| PUR w/o P-bit set | | PNR w/ 'P' bit set and w/o 'E' bit set |
|------------------------------------------------>| |------------------------------------------------>|
| | +------------------+ | +-------------------+
| | |post-authorization| | |post-authorization |
| | +------------------+ | |(CPAA becomes SPAA)|
| PUA w/o P-bit set | | +-------------------+
| PNA w/ 'P' bit set and w/o 'E' bit set |
|<------------------------------------------------| |<------------------------------------------------|
| | | | |
Figure 1: PaC-initiated Pre-authentication Call Flow Figure 1: PaC-initiated Pre-authentication Call Flow
PaC CPAA
An example call flow for PAA-initiated pre-authentication is shown in | |
Figure 2. | +------------------+
| |Pre-authentication|
PaC l-PAA r-PAA | |trigger |
| | | | +------------------+
| PANA w/o P-bit set | | | PAR w/'S' and 'E' bits set |
|<---------------------->| |
| | |
. . .
. . .
| | +------------------+
| | |Pre-authentication|
| | |trigger |
| | +------------------+
| PSR w/P-bit set |
|<------------------------------------------------| |<------------------------------------------------|
| PSA w/P-bit set | | PAN w/'S' and 'E' bits set |
|------------------------------------------------>| |------------------------------------------------>|
| PAR-PAN exchange w/P-bit set | | PAR-PAN exchange w/'E' bit set |
|<----------------------------------------------->|
| | +------------------+
| | |pre-authorization |
| | +------------------+
| PBR-PBA exchange w/P-bit set |
|<----------------------------------------------->| |<----------------------------------------------->|
| +------------------+
| |pre-authorization |
| +------------------+
| PAR w/'C' and 'E' bits set |
|<------------------------------------------------|
| PAN w/'C' and 'E' bits set |
|------------------------------------------------>|
. . . . . .
. . . . . .
+----------+ | | +----------+ |
| Movement | | | | Movement | |
+----------+ | | +----------+ |
| PUR w/o P-bit set | | PNR w/ 'P' bit set and w/o 'E' bit set |
|------------------------------------------------>| |------------------------------------------------>|
| | +------------------+ | +-------------------+
| | |post-authorization| | |post-authorization |
| | +------------------+ | |(CPAA becomes SPAA)|
| PUA w/o P-bit set | | +-------------------+
| PNA w/ 'P' bit set and w/o 'E' bit set |
|<------------------------------------------------| |<------------------------------------------------|
| | | | |
Figure 2: PAA-initiated Pre-authentication Call Flow Figure 2: PAA-initiated Pre-authentication Call Flow
4. PANA Extensions 4. PANA Extensions
A new P-flag is defined in Flags field of PANA header as follows. A new 'E' (prE-authentication) bit is defined in Flags field of PANA
header as follows.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R S N P r r r r r r r r r r r r| |R S C A P I E r r r r r r r r r|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E(PrE-authentication) When pre-authentication is performed, the 'E'
P(re-authentication) (prE-authentication) bit of PANA messages are set in order to
indicate whether this PANA run is for establishing a pre-
When pre-authentication is performed, the P-flag of PANA messages authorization SA. The exact usage of this bit is described in
are set in order to indicate whether this PANA run is for Section 3. This bit is to be assigned by IANA.
establishing a pre-authentication SA. The exact usage of this
flag is described in Section 3. This flag is to be assigned by
IANA.
5. Authorization and Accounting Considerations 5. Authorization and Accounting Considerations
A pre-authorization and a post-authorization for the PaC may have A pre-authorization and a post-authorization for the PaC may have
different authorization policies. For example, the pre-authorization different authorization policies. For example, the pre-authorization
policy may not allow the PaC to sent or receive packets through the policy may not allow the PaC to sent or receive packets through an
EP(s) under control of the preparing PAA, while both the pre- (Enforcement Point) that is under control of the CPAA, while both the
authorization and post-authorization policies may allow installing pre-authorization and post-authorization policies may allow
credentials to the EP(s), where the credentials are used for installing credentials to the EP, where the credentials are used for
establishing a security association for per-packet cryptographic establishing a security association for per-packet cryptographic
filtering. filtering.
In an access network where accounting is performed, accounting starts In an access network where accounting is performed, accounting starts
when the pre-authentication SA becomes the active SA by default. when the pre-authorization SA becomes the post-authorization SA by
Depending on the pre-authorization policy, accounting may start default. Depending on the pre-authorization policy, accounting may
immediately after the pre-authentication SA is established. start immediately after the pre-authorization SA is established.
6. Security Considerations 6. Security Considerations
Since the mechanism described in this document is designed to work Since the mechanism described in this document is designed to work
across multiple access networks, each EP (Enforcement Point) SHOULD across multiple access networks, each EP in the serving network
be configured to allow PANA messages to be forwarded between a PaC SHOULD be configured to allow PANA messages to be forwarded between a
and a preparing PAA in a different access network only if the PaC has PaC and a CPAA only if the PaC has a post-authorization SA with the
an active SA with a local PAA in order to avoid an unauthorized PaC SPAA in order to avoid an unauthorized PaC to initiate pre-
to initiate pre-authentication. Also, each access network that authentication. Also, each access network that supports pre-
supports pre-authentication SHOULD block pre-authentication attempts authentication SHOULD block pre-authentication attempts from networks
from networks from which a handover is not likely to occur. from which a handover is not likely to occur.
When pre-authentication is initiated by a remote PAA, it is possible When pre-authentication is initiated by a CPAA, it is possible that
that the PaC simultaneously communicates with multiple remote PAAs the PaC simultaneously communicates with multiple CPAAs initiating
initiating pre-authentication. In order to avoid possible resource pre-authentication. In order to avoid possible resource consumption
consumption attacks on the PaC caused by a blind attacker initiating attacks on the PaC caused by a blind attacker initiating pre-
pre-authentication for the PaC by changing source addresses, the PaC authentication for the PaC by changing source addresses, the PaC
SHOULD limit the maximum number of PAAs allowed to communicate. SHOULD limit the maximum number of CPAAs allowed to communicate.
The pre-authentication mechanism defined in this document does not
have an issue on context binding in which link-layer independent
context carried over pre-authentication signaling is bound to the
link-layer specific context [I-D.ietf-hokey-preauth-ps], because the
same EAP transport protocol (i.e., PANA) is used for normal
authentication and pre-authentication in the candidate network.
7. IANA Considerations 7. IANA Considerations
As described in Section 4, a new flag in the Flags field of PANA As described in Section 4, bit 6 of the Flags field of PANA Header
Header needs to be assigned by IANA. The new flag is bit 3 ('P're- needs to be assigned by IANA for the 'E' (prE-authentication) bit.
authentication).
8. Acknowledgments 8. Acknowledgments
The author would like to thank Alper Yegin, Ashutosh Dutta, Julien The author would like to thank Alper Yegin, Ashutosh Dutta, Julien
Bournelle and Sasikanth Bharadwaj for their valuable comments. Bournelle and Sasikanth Bharadwaj for their valuable comments.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-pana-pana] [I-D.ietf-pana-pana]
Forsberg, D., "Protocol for Carrying Authentication for Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
Network Access (PANA)", draft-ietf-pana-pana-10 (work in Yegin, "Protocol for Carrying Authentication for Network
progress), July 2005. Access (PANA)", draft-ietf-pana-pana-18 (work in
progress), September 2007.
[I-D.ietf-hokey-preauth-ps]
Ohba, Y., "EAP Pre-authentication Problem Statement",
draft-ietf-hokey-preauth-ps-01 (work in progress),
October 2007.
9.2. Informative References 9.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4067] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli,
"Context Transfer Protocol (CXTP)", RFC 4067, July 2005.
[I-D.ietf-pana-mobopts]
Forsberg, D., "PANA Mobility Optimizations",
draft-ietf-pana-mobopts-01 (work in progress),
October 2005.
[I-D.ietf-pana-cxtp]
Bournelle, J., "Use of Context Transfer Protocol (CXTP)
for PANA", draft-ietf-pana-cxtp-00 (work in progress),
October 2005.
Author's Address Author's Address
Yoshihiro Ohba Yoshihiro Ohba
Toshiba America Research, Inc. Toshiba America Research, Inc.
1 Telcordia Drive 1 Telcordia Drive
Piscateway, NJ 08854 Piscateway, NJ 08854
USA USA
Phone: +1 732 699 5365 Phone: +1 732 699 5365
Email: yohba@tari.toshiba.com Email: yohba@tari.toshiba.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 18, line 29 skipping to change at page 10, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. 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 (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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 52 change blocks. 
315 lines changed or deleted 220 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/