draft-ietf-pana-preauth-02.txt   draft-ietf-pana-preauth-03.txt 
PANA Working Group Y. Ohba PANA Working Group Y. Ohba
Internet-Draft Toshiba Internet-Draft Toshiba
Expires: May 21, 2008 November 18, 2007 Expires: April 27, 2009 October 24, 2008
Pre-authentication Support for PANA Pre-authentication Support for PANA
draft-ietf-pana-preauth-02 draft-ietf-pana-preauth-03
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 May 21, 2008. This Internet-Draft will expire on April 27, 2009.
Copyright Notice
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 Protocol for carrying
proactively establishing a PANA SA (Security Association) between a Authentication for Network Access (PANA) for proactively establishing
PaC in an access network and a PAA in another access network to which a PANA SA (Security Association) between a PaC in one access network
the PaC may move. The proposed method operates across multiple and a PAA in another access network to which the PaC may move. The
administrative domains. proposed method operates across multiple 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminogy . . . . . . . . . . . . . . . . . . . . . . . . . . 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. Authorization and Accounting Considerations . . . . . . . . . 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
Intellectual Property and Copyright Statements . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 10
1. Introduction 1. Introduction
The PANA protocol [I-D.ietf-pana-pana] carries EAP messages between a The Protocol for carrying Authentication for Network Access (PANA)
PaC (PANA Client) and a PAA (PANA Authentication Agent) in the access [RFC5191] carries EAP messages between a PaC (PANA Client) and a PAA
network. If the PaC is a mobile device and is capable of moving one (PANA Authentication Agent) in the access network. If the PaC is a
access network to another while running its applications, it is mobile device and is capable of moving one access network to another
critical for the PaC to perform a handover seamlessly without while running its applications, it is critical for the PaC to perform
degrading the performance of the applications during the handover a handover seamlessly without degrading the performance of the
period. When the handover requires the PaC to establish a PANA applications during the handover period. When the handover requires
session with the PAA in the new access network, the signaling to the PaC to establish a PANA session with the PAA in the new access
establish the PANA session should be completed as fast as possible. network, the signaling to establish the PANA session should be
completed as fast as possible.
This document defines an extension to the PANA protocol This document defines an extension to the PANA protocol [RFC5191]
[I-D.ietf-pana-pana] used for proactively executing EAP used for proactively executing EAP authentication and establishing a
authentication and establishing a PANA SA (Security Association) PANA SA (Security Association) between a PaC in an access network and
between a PaC in an access network and a PAA in another access a PAA in another access network to which the PaC may move. The
network to which the PaC may move. The proposed method operates proposed method operates across multiple AAA domains. The extension
across multiple AAA domains. The extension to the PANA protocol is to the PANA protocol is designed to realize direct pre-authentication
designed to realize direct pre-authentication defined in defined in [I-D.ietf-hokey-preauth-ps].
[I-D.ietf-hokey-preauth-ps].
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 [RFC5191].
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. For
simplicity, this document assumes that there is only one SPAA in simplicity, this document assumes that there is only one SPAA in
the serving network while the pre-authentication mechanism the serving network while the pre-authentication mechanism
described in this document is generally applicable to the case described in this document is generally applicable to the case
where there are two or more SPAAs in the serving network. 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
skipping to change at page 5, line 19 skipping to change at page 5, line 19
pre-authentication. Otherwise, it MUST silently discard the pre-authentication. Otherwise, it MUST silently discard the
message. message.
o Once the PaC and CPAA have agreed on performing pre-authentication o Once the PaC and CPAA have agreed on performing pre-authentication
using the 'S' (Start) and 'E' (prE-authentication) bits, the using the 'S' (Start) and 'E' (prE-authentication) bits, the
subsequent PANA messages exchanged between them MUST have the 'E' subsequent PANA messages exchanged between them MUST have the 'E'
(prE-authentication) bit set. (prE-authentication) bit set.
When a CPAA with which the PaC has a pre-authorization SA becomes the When a CPAA with which the PaC has a pre-authorization SA becomes the
SPAA due to, e.g., movement of the PaC, the PaC performs an IP SPAA due to, e.g., movement of the PaC, the PaC performs an IP
address update procedure defined in Section 5.6 of address update procedure defined in Section 5.6 of [RFC5191] in order
[I-D.ietf-pana-pana] in order to update the SPAA with the PaC's new to update the SPAA with the PaC's new address obtained from the new
address obtained from the new serving network. PANA-Notification- serving network. PANA-Notification-Request (PNR) and PANA-
Request (PNR) and PANA-Notification-Answer (PNA) messages with 'P' Notification-Answer (PNA) messages with 'P' (Ping) bit set are used
(Ping) bit set are used for this purpose. The completion of the IP for this purpose. The completion of the IP address update procedure
address update procedure will change the pre-authorization SA to a will change the pre-authorization SA to a post-authorization SA. In
post-authorization SA. In this case, the 'E' MUST NOT be set in the this case, the 'E' MUST NOT be set in the PNR and PNA messages and
PNR and PNA messages and subsequent PANA messages. subsequent PANA messages.
If there is another CPAA with which the PaC has a pre-authorization If there is another CPAA with which the PaC has a pre-authorization
SA and the PaC wants to keep the pre-authorization SA after the SA and the PaC wants to keep the pre-authorization SA after the
change of SPAA, the PaC also performs an IP address update procedure change of SPAA, the PaC also performs an IP address update procedure
defined in Section 5.6 of [I-D.ietf-pana-pana] in order to update the defined in Section 5.6 of [RFC5191] in order to update the CPAA with
CPAA with the PaC's new address. PNR and PNA messages with 'P' the PaC's new address. PNR and PNA messages with 'P' (Ping) bit set
(Ping) bit set is used for this purpose. In this case, the 'E' (prE- is used for this purpose. In this case, the 'E' (prE-authentication)
authentication) bit MUST be set in the PNR and PNA messages and bit MUST be set in the PNR and PNA messages and subsequent PANA
subsequent PANA messages. The IP address update procedure with the messages. The IP address update procedure with the CPAA will not
CPAA will not change the pre-authorization SA to a post-authorization change the pre-authorization SA to a post-authorization SA.
SA.
The pre-authorization SA and the corresponding PANA session between The pre-authorization SA and the corresponding PANA session between
the PaC and a CPAA is deleted by entering the termination phase of the PaC and a CPAA is deleted by entering 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 1, initiated pre-authentication are shown in Figure 1 and Figure 2,
respectively. respectively.
PaC CPAA PaC CPAA
| | | |
+------------------+ | +------------------+ |
|Pre-authentication| | |Pre-authentication| |
|trigger | | |trigger | |
+------------------+ | +------------------+ |
| PCI w/'E' bit set | | PCI w/'E' bit set |
|------------------------------------------------>| |------------------------------------------------>|
skipping to change at page 8, line 15 skipping to change at page 8, line 15
(prE-authentication) bit of PANA messages are set in order to (prE-authentication) bit of PANA messages are set in order to
indicate whether this PANA run is for establishing a pre- indicate whether this PANA run is for establishing a pre-
authorization SA. The exact usage of this bit is described in authorization SA. The exact usage of this bit is described in
Section 3. This bit is to be assigned by IANA. Section 3. This bit 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 an policy may not allow the PaC to sent or receive packets through an
(Enforcement Point) that is under control of the CPAA, while both the Enforcement Point (EP) that is under control of the CPAA, while both
pre-authorization and post-authorization policies may allow the pre-authorization and post-authorization policies may allow
installing credentials to the EP, 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-authorization SA becomes the post-authorization SA by when the pre-authorization SA becomes the post-authorization SA by
default. Depending on the pre-authorization policy, accounting may default. Depending on the pre-authorization policy, accounting may
start immediately after the pre-authorization SA is established. start immediately after the pre-authorization SA is established.
6. Security Considerations 6. Security Considerations
skipping to change at page 9, line 19 skipping to change at page 9, line 19
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] [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
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)", draft-ietf-pana-pana-18 (work in Access (PANA)", RFC 5191, May 2008.
progress), September 2007.
[I-D.ietf-hokey-preauth-ps] [I-D.ietf-hokey-preauth-ps]
Ohba, Y., "EAP Pre-authentication Problem Statement", Ohba, Y., "EAP Pre-authentication Problem Statement",
draft-ietf-hokey-preauth-ps-01 (work in progress), draft-ietf-hokey-preauth-ps-04 (work in progress),
October 2007. September 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.
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 5305
Email: yohba@tari.toshiba.com Email: yohba@tari.toshiba.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 10, line 44 skipping to change at line 401
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 17 change blocks. 
56 lines changed or deleted 49 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/