draft-ietf-pana-preauth-03.txt   draft-ietf-pana-preauth-04.txt 
PANA Working Group Y. Ohba PANA Working Group Y. Ohba
Internet-Draft Toshiba Internet-Draft Toshiba
Expires: April 27, 2009 October 24, 2008 Intended status: Standards Track December 3, 2008
Expires: June 6, 2009
Pre-authentication Support for PANA Pre-authentication Support for PANA
draft-ietf-pana-preauth-03 draft-ietf-pana-preauth-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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.
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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 April 27, 2009. This Internet-Draft will expire on June 6, 2009.
Copyright Notice
Copyright (c) 2008 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
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 SA (Security Association) between a PaC in one access network
and a PAA in another access network to which the PaC may move. The and a PAA in another access network to which the PaC may move. The
proposed method operates across multiple 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
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 one access network to another
while running its applications, it is critical for the PaC to perform while running its applications, it is critical for the PaC to perform
a handover seamlessly without degrading the performance of the a handover seamlessly without degrading the performance of the
applications during the handover period. When the handover requires applications during the handover period. When the handover requires
skipping to change at page 4, line 49 skipping to change at page 4, line 49
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 are set in order to indicate whether this PANA run is
for pre-authentication. Use of pre-authentication is negotiated as for 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 PCI message MUST be unicast. The CPAA responds with a
PANA-Start-Request (PSR) message with the 'S' (Start) and 'E' PANA-Auth-Request (PAR) message with the 'S' (Start) and 'E' (prE-
(prE-authentication) bits set only if it supports pre- authentication) bits set only if it supports pre-authentication.
authentication. Otherwise, it MUST silently discard the message. Otherwise, it MUST silently discard the message.
o When a CPAA initiates pre-authentication, it sends a PSR 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-Start-Answer (PSA) 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, 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
skipping to change at page 9, line 23 skipping to change at page 9, line 23
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
[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.
[I-D.ietf-hokey-preauth-ps]
Ohba, Y., "EAP Pre-authentication Problem Statement",
draft-ietf-hokey-preauth-ps-04 (work in progress),
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.
[I-D.ietf-hokey-preauth-ps]
Ohba, Y., "EAP Pre-authentication Problem Statement",
draft-ietf-hokey-preauth-ps-04 (work in progress),
September 2008.
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
Email: yohba@tari.toshiba.com Email: yohba@tari.toshiba.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 13 change blocks. 
25 lines changed or deleted 35 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/