draft-ietf-pana-preauth-04.txt   draft-ietf-pana-preauth-05.txt 
PANA Working Group Y. Ohba PANA Working Group Y. Ohba
Internet-Draft Toshiba Internet-Draft Toshiba
Intended status: Standards Track December 3, 2008 Intended status: Standards Track April 13, 2009
Expires: June 6, 2009 Expires: October 15, 2009
Pre-authentication Support for PANA Pre-authentication Support for PANA
draft-ietf-pana-preauth-04 draft-ietf-pana-preauth-05
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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 June 6, 2009. This Internet-Draft will expire on October 15, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2008 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
This document defines an extension to the Protocol for carrying This document defines an extension to the Protocol for carrying
Authentication for Network Access (PANA) for proactively establishing Authentication for Network Access (PANA) for proactively establishing
a PANA SA (Security Association) between a PaC in one access network a PANA security association between a PANA client in one access
and a PAA in another access network to which the PaC may move. The network and a PANA authentication agent in another access network to
proposed method operates across multiple administrative domains. which the PANA client may move.
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Pre-authentication Procedure . . . . . . . . . . . . . . . . . 4 3. Pre-authentication Procedure . . . . . . . . . . . . . . . . . 4
4. PANA Extensions . . . . . . . . . . . . . . . . . . . . . . . . 7 4. PANA Extensions . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Authorization and Accounting Considerations . . . . . . . . . . 8 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The Protocol for carrying Authentication for Network Access (PANA) The Protocol for carrying Authentication for Network Access (PANA)
[RFC5191] carries EAP messages between a PaC (PANA Client) and a PAA [RFC5191] carries EAP messages between a PaC (PANA Client) and a PAA
(PANA Authentication Agent) in the access network. If the PaC is a (PANA Authentication Agent) in the access network. If the PaC is a
mobile device and is capable of moving one access network to another mobile device and is capable of moving from one access network to
while running its applications, it is critical for the PaC to perform another while running its applications, it is critical for the PaC to
a handover seamlessly without degrading the performance of the perform a handover seamlessly without degrading the performance of
applications during the handover period. When the handover requires the applications during the handover period. When the handover
the PaC to establish a PANA session with the PAA in the new access requires the PaC to establish a PANA session with the PAA in the new
network, the signaling to establish the PANA session should be access network, the signaling to establish the PANA session should be
completed as fast as possible. completed as fast as possible. See [I-D.ietf-hokey-preauth-ps] for
the handover latency requirements.
This document defines an extension to the PANA protocol [RFC5191] This document defines an extension to the PANA protocol [RFC5191]
used for proactively executing EAP authentication and establishing a used for proactively executing EAP authentication and establishing a
PANA SA (Security Association) between a PaC in an access network and 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 a PAA in another access network to which the PaC may move. The
proposed method operates across multiple AAA domains. The extension extension to the PANA protocol is designed to realize direct pre-
to the PANA protocol is designed to realize direct pre-authentication authentication defined in [I-D.ietf-hokey-preauth-ps]. How to
defined in [I-D.ietf-hokey-preauth-ps]. realize authorization and accounting with the use of the pre-
authentication extension is out of the scope of this document.
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. Terminology
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 [RFC5191]. terms defined in [RFC5191].
Serving Network: The access network through which the host gains
access to the Internet/intranet.
Candidate Network: An access network that is a potential target of
host's handover.
Serving PAA (SPAA): A PAA that resides in the serving network and Serving PAA (SPAA): A PAA that resides in the serving network and
provides network access authentication for a particular PaC. For provides network access authentication for a particular PaC.
simplicity, this document assumes that there is only one SPAA in
the serving network while the pre-authentication mechanism
described in this document is generally applicable to the case
where there are two or more SPAAs in the serving network.
Candidate PAA (CPAA): A PAA that resides in a candidate network to 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 which the PaC may move. A CPAA for a particular PaC may be a SPAA
for another PaC. for another PaC.
Pre-authentication: Pre-authentication refers to EAP pre- Pre-authentication: Pre-authentication refers to EAP pre-
authentication and defined as the utilization of EAP to pre- authentication and defined as the utilization of EAP to pre-
establish EAP keying material on an authenticator prior to arrival establish EAP keying material on an authenticator prior to arrival
of the peer at the access network served by that authenticator of the peer at the access network served by that authenticator
[I-D.ietf-hokey-preauth-ps]. In this draft, EAP pre- [I-D.ietf-hokey-preauth-ps]. In this draft, EAP pre-
authentication is performed between a PaC and a CPAA. authentication is performed between a PaC and a CPAA.
Pre-authorization: An authorization for a PaC, made by a CPAA for
the PaC at the time of pre-authentication.
Post-authorization: An authorization for a PaC, made by a CPAA for
the PaC when the CPAA becomes the SPAA for the PaC.
Pre-authorization SA: A PANA SA established between a PaC and its
CPAA.
Post-authorization SA: A PANA SA established between the PaC and its
SPAA.
3. Pre-authentication Procedure 3. Pre-authentication Procedure
A PaC that supports pre-authentication may establish a PANA session A PaC that supports pre-authentication may establish a PANA session
for each CPAA. for each CPAA.
There may be several mechanisms for a PaC and a CPAA to discover each There may be several mechanisms for a PaC and a CPAA to discover each
other. However, such mechanisms are out of the scope of this other. However, such mechanisms are out of the scope of this
document. document.
There may be a number of criteria for CPAA selection, the timing to There may be a number of criteria for CPAA selection, the timing to
start pre-authentication and the timing to make a pre-authorization start pre-authentication and the timing as to when the CPAA becomes
SA a post-authorization SA (and hence the CPAA becomes the SPAA). the SPAA. Such criteria can be implementation specific and thus are
Such criteria can be implementation specific and thus are outside the outside the scope of this document.
scope of this document.
Pre-authentication may be initiated by both a PaC and a CPAA. A new Pre-authentication may be initiated by both a PaC and a CPAA. A new
'E' (prE-authentication) bit is defined in the PANA header. When 'E' (prE-authentication) bit is defined in the PANA header. When
pre-authentication is performed, the 'E' (prE-authentication) bit of pre-authentication is performed, the 'E' (prE-authentication) bit of
PANA messages are set in order to indicate whether this PANA run is PANA messages is set in order to indicate that this PANA run is for
for pre-authentication. Use of pre-authentication is negotiated as pre-authentication. Use of pre-authentication is negotiated as
follows. follows.
o When a PaC initiates pre-authentication, it sends a PANA-Client- o When a PaC initiates pre-authentication, it sends a PANA-Client-
Initiation (PCI) message with the 'E' (prE-authentication) bit Initiation (PCI) message with the 'E' (prE-authentication) bit
set. The PCI message MUST be unicast. The CPAA responds with a set. The CPAA responds with a PANA-Auth-Request (PAR) message
PANA-Auth-Request (PAR) message with the 'S' (Start) and 'E' (prE- with the 'S' (Start) and 'E' (prE-authentication) bits set only if
authentication) bits set only if it supports pre-authentication. it supports pre-authentication. Otherwise, the 'E' (prE-
Otherwise, it MUST silently discard the message. authentication) bit of the PAR message will be cleared according
to Section 6.2 of [RFC5191], which results in a negotiation
failure.
o When a CPAA initiates pre-authentication, it sends a PAR message o When a CPAA initiates pre-authentication, it sends a PAR message
with the 'S' (Start) and 'E' (prE-authentication) bits set. The with the 'S' (Start) and 'E' (prE-authentication) bits set. The
PaC responds with a PANA-Auth-Answer (PAN) message with the 'S' PaC responds with a PANA-Auth-Answer (PAN) message with the 'S'
(Start) and 'E' (prE-authentication) bits set only if it supports (Start) and 'E' (prE-authentication) bits set only if it supports
pre-authentication. Otherwise, it MUST silently discard the pre-authentication. Otherwise, the 'E' (prE-authentication) bit
message. of the PAN message will be cleared according to Section 6.2 of
[RFC5191], which results in a negotiation failure.
o Once the PaC and CPAA have agreed 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.
When a CPAA with which the PaC has a pre-authorization SA becomes the o Once the PaC and CPAA have successfully negotiated on performing
SPAA due to, e.g., movement of the PaC, the PaC performs an IP pre-authentication using the 'S' (Start) and 'E' (prE-
address update procedure defined in Section 5.6 of [RFC5191] in order authentication) bits, the subsequent PANA messages exchanged
to update the SPAA with the PaC's new address obtained from the new between them MUST have the 'E' (prE-authentication) bit set until
serving network. PANA-Notification-Request (PNR) and PANA- CPAA becomes SPAA of the PaC. The PaC may conduct this exchange
Notification-Answer (PNA) messages with 'P' (Ping) bit set are used with more than one CPAA. If the PaC and CPAA have failed to
for this purpose. The completion of the IP address update procedure negotiate on performing pre-authentication, the PaC or CPAA that
will change the pre-authorization SA to a post-authorization SA. In sent a message with both the 'S' (Start) and 'E' (prE-
this case, the 'E' MUST NOT be set in the PNR and PNA messages and authentication) bits set MUST discard the message received from
subsequent PANA messages. the peer with 'S' (Start) bit set and the 'E' (prE-authentication)
bit cleared, which will eventually result in PANA session
termination.
If there is another CPAA with which the PaC has a pre-authorization When a CPAA of the PaC becomes the SPAA due to, e.g., movement of the
SA and the PaC wants to keep the pre-authorization SA after the PaC, the PaC informs the PAA of the change using PANA-Notification-
change of SPAA, the PaC also performs an IP address update procedure Request (PNR) and PANA-Notification-Answer (PNA) messages with the
defined in Section 5.6 of [RFC5191] in order to update the CPAA with 'P' (Ping) bit set and the 'E' (prE-authentication) bit cleared. The
the PaC's new address. PNR and PNA messages with 'P' (Ping) bit set 'E' (prE-authentication) bit MUST be cleared in subsequent PANA
is used for this purpose. In this case, the 'E' (prE-authentication) messages.
bit MUST be set in the PNR and PNA messages and subsequent PANA
messages. The IP address update procedure with the CPAA will not
change the pre-authorization SA to a post-authorization SA.
The pre-authorization SA and the corresponding PANA session between The PANA session between the PaC and a CPAA is deleted by entering
the PaC and a CPAA is deleted by entering the termination phase of the termination phase of the PANA protocol.
the PANA protocol.
Example call flows for PaC-initiated pre-authentication and PAA- Example call flows for PaC-initiated pre-authentication and PAA-
initiated pre-authentication are shown in Figure 1 and Figure 2, initiated pre-authentication are shown in Figure 1 and Figure 2,
respectively. respectively. Note that EAP authentication is performed over PAR and
PAN exchanges.
PaC CPAA PaC CPAA
| | | |
+------------------+ | +------------------+ |
|Pre-authentication| | |Pre-authentication| |
|trigger | | |trigger | |
+------------------+ | +------------------+ |
| PCI w/'E' bit set | | PCI w/'E' bit set |
|------------------------------------------------>| |------------------------------------------------>|
| PAR w/'S' and 'E' bits set | | PAR w/'S' and 'E' bits set |
|<------------------------------------------------| |<------------------------------------------------|
| PAN w/'S' and 'E' bits set | | PAN w/'S' and 'E' bits set |
|------------------------------------------------>| |------------------------------------------------>|
| PAR-PAN exchange w/'E' bit set | | PAR-PAN exchange w/'E' bit set |
|<----------------------------------------------->| |<----------------------------------------------->|
| +------------------+
| |pre-authorization |
| +------------------+
| PAR w/'C' and 'E' bits set | | PAR w/'C' and 'E' bits set |
|<------------------------------------------------| |<------------------------------------------------|
| PAN w/'C' and 'E' bits set | | PAN w/'C' and 'E' bits set |
|------------------------------------------------>| |------------------------------------------------>|
. . . . . .
. . . . . .
+----------+ | +----------+ |
| Movement | | | Movement | |
+----------+ | +----------+ |
| PNR w/ 'P' bit set and w/o 'E' bit set | | PNR w/ 'P' bit set and w/o 'E' bit set |
|------------------------------------------------>| |------------------------------------------------>|
| +-------------------+ | +-----------------+
| |post-authorization | | |CPAA becomes SPAA|
| |(CPAA becomes SPAA)| | +-----------------+
| +-------------------+
| PNA w/ 'P' bit set and w/o 'E' 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 PaC CPAA
| | | |
| +------------------+ | +------------------+
| |Pre-authentication| | |Pre-authentication|
| |trigger | | |trigger |
| +------------------+ | +------------------+
| PAR w/'S' and 'E' bits set | | PAR w/'S' and 'E' bits set |
|<------------------------------------------------| |<------------------------------------------------|
| PAN w/'S' and 'E' bits set | | PAN w/'S' and 'E' bits set |
|------------------------------------------------>| |------------------------------------------------>|
| PAR-PAN exchange w/'E' bit set | | PAR-PAN exchange w/'E' bit set |
|<----------------------------------------------->| |<----------------------------------------------->|
| +------------------+
| |pre-authorization |
| +------------------+
| PAR w/'C' and 'E' bits set | | PAR w/'C' and 'E' bits set |
|<------------------------------------------------| |<------------------------------------------------|
| PAN w/'C' and 'E' bits set | | PAN w/'C' and 'E' bits set |
|------------------------------------------------>| |------------------------------------------------>|
. . . . . .
. . . . . .
+----------+ | +----------+ |
| Movement | | | Movement | |
+----------+ | +----------+ |
| PNR w/ 'P' bit set and w/o 'E' bit set | | PNR w/ 'P' bit set and w/o 'E' bit set |
|------------------------------------------------>| |------------------------------------------------>|
| +-------------------+ | +-----------------+
| |post-authorization | | |CPAA becomes SPAA|
| |(CPAA becomes SPAA)| | +-----------------+
| +-------------------+
| PNA w/ 'P' bit set and w/o 'E' 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 'E' (prE-authentication) bit is defined in Flags field of PANA A new 'E' (prE-authentication) bit is defined in Flags field of PANA
header as follows. 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 C A P I E 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' E(PrE-authentication) When pre-authentication is performed, the 'E'
(prE-authentication) bit of PANA messages are set in order to (prE-authentication) bit of PANA messages is set in order to
indicate whether this PANA run is for establishing a pre- indicate whether this PANA run is for pre-authentication. The
authorization SA. The exact usage of this bit is described in exact usage of this bit is described in Section 3. This bit is to
Section 3. This bit is to be assigned by IANA. be assigned by IANA.
5. Authorization and Accounting Considerations 5. Backward Compatibility
A pre-authorization and a post-authorization for the PaC may have Backward compatibility between a PANA entity that does not support
different authorization policies. For example, the pre-authorization the pre-authentication extension and another PANA entity that
policy may not allow the PaC to sent or receive packets through an supports the pre-authentication extension is maintained as follows.
Enforcement Point (EP) that is under control of the CPAA, while both
the pre-authorization and post-authorization policies may allow
installing credentials to the EP, where the credentials are used for
establishing a security association for per-packet cryptographic
filtering.
In an access network where accounting is performed, accounting starts When a PaC that supports the pre-authentication extension initiates
when the pre-authorization SA becomes the post-authorization SA by PANA pre-authentication by sending a PCI message with the 'E' (prE-
default. Depending on the pre-authorization policy, accounting may authentication) bit set to a PAA that does not support the pre-
start immediately after the pre-authorization SA is established. authentication extension, the PAA will ignore the E-bit according to
Section 6.2 of [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.
Similarly, when a PAA that supports the pre-authentication extension
initiates PANA pre-authentication by sending a PAR message with the
'E' (prE-authentication) bit set to a PaC that does not support the
pre-authentication extension, the PaC will ignore the E-bit, and try
to process the message as a normal authentication attempt. As a
result, the PAA will receive a PAN message with the 'E' (prE-
authentication) bit cleared.
In both cases, the negotiation on the use of pre-authentication will
fail and eventually the PANA session will be terminated as described
in Section Section 3.
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 in the serving network across multiple access networks, an access network may be configured
SHOULD be configured to allow PANA messages to be forwarded between a to allow or disallow PANA messages from a set of access networks.
PaC and a CPAA only if the PaC has a post-authorization SA with the
SPAA in order to avoid an unauthorized PaC to initiate pre-
authentication. Also, each access network that supports pre-
authentication SHOULD block pre-authentication attempts from networks
from which a handover is not likely to occur.
When pre-authentication is initiated by a CPAA, it is possible that
the PaC simultaneously communicates with multiple CPAAs initiating
pre-authentication. In order to avoid possible resource consumption
attacks on the PaC caused by a blind attacker initiating pre-
authentication for the PaC by changing source addresses, the PaC
SHOULD limit the maximum number of CPAAs allowed to communicate.
The pre-authentication mechanism defined in this document does not When pre-authentication is initiated by CPAA, it is possible that
have an issue on context binding in which link-layer independent multiple CPAAs simultaneously initiate pre-authentication for the
context carried over pre-authentication signaling is bound to the same PaC. In order to avoid possible resource consumption attacks on
link-layer specific context [I-D.ietf-hokey-preauth-ps], because the the PaC caused by an attacker initiating pre-authentication for the
same EAP transport protocol (i.e., PANA) is used for normal PaC by changing source addresses, the PaC SHOULD limit the maximum
authentication and pre-authentication in the candidate network. number of CPAAs allowed to communicate.
7. IANA Considerations 7. IANA Considerations
As described in Section 4, bit 6 of the Flags field of PANA Header As described in Section 4, bit 6 of the Flags field of the PANA
needs to be assigned by IANA for the 'E' (prE-authentication) bit. Header needs to be assigned by IANA for the 'E' (prE-authentication)
bit.
8. Acknowledgments 8. Acknowledgments
The author would like to thank Alper Yegin, Ashutosh Dutta, Julien The author would like to thank Alper Yegin, Basavaraj Patil, Ashutosh
Bournelle and Sasikanth Bharadwaj for their valuable comments. Dutta, Julien Bournelle, Sasikanth Bharadwaj, Subir Das, Rafa Marin
Lopez, Lionel Morand, Victor Fajardo, Glen Zorn and Qin Wu for their
support and valuable feedback.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
Yegin, "Protocol for Carrying Authentication for Network Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", RFC 5191, May 2008. Access (PANA)", RFC 5191, May 2008.
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.
[I-D.ietf-hokey-preauth-ps] [I-D.ietf-hokey-preauth-ps]
Ohba, Y., "EAP Pre-authentication Problem Statement", Wu, W. and Y. Ohba, "EAP Pre-authentication Problem
draft-ietf-hokey-preauth-ps-04 (work in progress), Statement", draft-ietf-hokey-preauth-ps-06 (work in
September 2008. progress), March 2009.
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 5305 Phone: +1 732 699 5305
 End of changes. 35 change blocks. 
141 lines changed or deleted 121 lines changed or added

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