PANA Working Group Y. Ohba
Internet-Draft Toshiba
Intended status: Standards Track A. Yegin
Expires: April 14, 2010 Samsung
October 11, 2009
Pre-authentication Support for PANA
draft-ietf-pana-preauth-07
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 14, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document defines an extension to the Protocol for carrying
Authentication for Network Access (PANA) for proactively establishing
Ohba & Yegin Expires April 14, 2010 [Page 1]
Internet-Draft Pre-authentication Support for PANA October 2009
a PANA security association between a PANA client in one access
network and a PANA authentication agent in another access network to
which the PANA client may move.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Pre-authentication Procedure . . . . . . . . . . . . . . . . . 4
4. PANA Extensions . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Ohba & Yegin Expires April 14, 2010 [Page 2]
Internet-Draft Pre-authentication Support for PANA October 2009
1. Introduction
The Protocol for carrying Authentication for Network Access (PANA)
[RFC5191] carries EAP messages between a PaC (PANA Client) and a PAA
(PANA Authentication Agent) in the access network. If the PaC is a
mobile device and is capable of moving from one access network to
another while running its applications, it is critical for the PaC to
perform a handover seamlessly without degrading the performance of
the applications during the handover period. When the handover
requires the PaC to establish a PANA session with the PAA in the new
access network, the signaling to establish the PANA session should be
completed as fast as possible. See [I-D.ietf-hokey-preauth-ps] for
the handover latency requirements.
This document defines an extension to the PANA protocol [RFC5191]
used for proactively executing EAP authentication and establishing a
PANA SA (Security Association) between a PaC in an access network and
a PAA in another access network to which the PaC may move. The
extension to the PANA protocol is designed to realize direct pre-
authentication defined in [I-D.ietf-hokey-preauth-ps]. How to
realize authorization and accounting with the use of the pre-
authentication extension is out of the scope of this document.
1.1. Specification of Requirements
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in [RFC2119].
2. Terminology
The following terms are used in this document in addition to the
terms defined in [RFC5191].
Serving Network: The access network to which the host is currently
attached.
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
provides network access authentication for a particular PaC.
Ohba & Yegin Expires April 14, 2010 [Page 3]
Internet-Draft Pre-authentication Support for PANA October 2009
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.
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.
3. Pre-authentication Procedure
A PaC that supports pre-authentication may establish a PANA session
for each CPAA.
There may be several mechanisms for a PaC to discover a CPAA. IEEE
802.21 [802.21] Information Service is used for the default CPAA
discovery mechanism.
There may be a number of criteria for CPAA selection, the timing to
start pre-authentication and the timing as to when the CPAA becomes
the SPAA. Such criteria can be implementation specific and thus are
outside the scope of this document.
Pre-authentication is initiated by a PaC in a similar way as normal
authentication. A new 'E' (prE-authentication) bit is defined in the
PANA header. When pre-authentication is performed, the 'E' (prE-
authentication) bit of PANA messages is set in order to indicate that
this PANA run is for pre-authentication. Use of pre-authentication
is negotiated as follows.
o When a PaC initiates pre-authentication, it sends a PANA-Client-
Initiation (PCI) message with the 'E' (prE-authentication) bit
set. The CPAA responds with a PANA-Auth-Request (PAR) message
with the 'S' (Start) and 'E' (prE-authentication) bits set only if
it supports pre-authentication. Otherwise, the 'E' (prE-
authentication) bit of the PAR message will be cleared according
to Section 6.2 of [RFC5191], which results in a negotiation
failure.
o Once the PaC and CPAA have successfully negotiated on performing
pre-authentication using the 'S' (Start) and 'E' (prE-
authentication) bits, the subsequent PANA messages exchanged
between them MUST have the 'E' (prE-authentication) bit set until
CPAA becomes SPAA of the PaC. The PaC may conduct this exchange
with more than one CPAA. If the PaC and CPAA have failed to
Ohba & Yegin Expires April 14, 2010 [Page 4]
Internet-Draft Pre-authentication Support for PANA October 2009
negotiate on performing pre-authentication, the PaC or CPAA that
sent a message with both the 'S' (Start) and 'E' (prE-
authentication) bits set MUST discard the message received from
the peer with 'S' (Start) bit set and the 'E' (prE-authentication)
bit cleared, which will eventually result in PANA session
termination.
When a CPAA of the PaC becomes the SPAA due to, e.g., movement of the
PaC, the PaC informs the PAA of the change using PANA-Notification-
Request (PNR) and PANA-Notification-Answer (PNA) messages with the
'P' (Ping) bit set and the 'E' (prE-authentication) bit cleared. The
'E' (prE-authentication) bit MUST be cleared in subsequent PANA
messages.
The PANA session between the PaC and a CPAA is deleted by entering
the termination phase of the PANA protocol.
Example call flows for pre-authentication is shown in Figure 1. Note
that EAP authentication is performed over PAR and PAN exchanges.
Ohba & Yegin Expires April 14, 2010 [Page 5]
Internet-Draft Pre-authentication Support for PANA October 2009
PaC CPAA
| |
+------------------+ |
|Pre-authentication| |
|trigger | |
+------------------+ |
| PCI w/'E' bit set |
|------------------------------------------------>|
| PAR w/'S' and 'E' bits set |
|<------------------------------------------------|
| PAN w/'S' and 'E' bits set |
|------------------------------------------------>|
| PAR-PAN exchange w/'E' bit set |
|<----------------------------------------------->|
| PAR w/'C' and 'E' bits set |
|<------------------------------------------------|
| PAN w/'C' and 'E' bits set |
|------------------------------------------------>|
. . .
. . .
+----------+ |
| Movement | |
+----------+ |
| PNR w/ 'P' bit set and w/o 'E' bit set |
|------------------------------------------------>|
| +-----------------+
| |CPAA becomes SPAA|
| +-----------------+
| PNA w/ 'P' bit set and w/o 'E' bit set |
|<------------------------------------------------|
| |
Figure 1: Pre-authentication Call Flow
4. PANA Extensions
A new 'E' (prE-authentication) bit is defined in Flags field of PANA
header as follows.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R S C A P I E r r r r r r r r r|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ohba & Yegin Expires April 14, 2010 [Page 6]
Internet-Draft Pre-authentication Support for PANA October 2009
E(PrE-authentication) When pre-authentication is performed, the 'E'
(prE-authentication) bit of PANA messages is set in order to
indicate whether this PANA run is for pre-authentication. The
exact usage of this bit is described in Section 3. This bit is to
be assigned by IANA.
5. Backward Compatibility
Backward compatibility between a PANA entity that does not support
the pre-authentication extension and another PANA entity that
supports the pre-authentication extension is maintained as follows.
When a PaC that supports the pre-authentication extension initiates
PANA pre-authentication by sending a PCI message with the 'E' (prE-
authentication) bit set to a PAA that does not support the pre-
authentication extension, the PAA will ignore the E-bit according to
Section 6.2 of [RFC5191], and try to process the message as a normal
authentication attempt. As a result, the PaC will receive a PAR
message with the 'E' (prE-authentication) bit cleared. In this case,
the negotiation on the use of pre-authentication will fail and
eventually the PANA session will be terminated as described in
Section Section 3.
6. Security Considerations
Since the mechanism described in this document is designed to work
across multiple access networks, an access network may be configured
to allow or disallow PANA messages from a set of access networks.
7. IANA Considerations
As described in Section 4, bit 6 of the Flags field of the PANA
Header needs to be assigned by IANA for the 'E' (prE-authentication)
bit.
8. Acknowledgments
The author would like to thank Basavaraj Patil, Ashutosh Dutta,
Julien Bournelle, Sasikanth Bharadwaj, Subir Das, Rafa Marin Lopez,
Lionel Morand, Victor Fajardo, Glen Zorn and Qin Wu for their support
and valuable feedback.
9. References
Ohba & Yegin Expires April 14, 2010 [Page 7]
Internet-Draft Pre-authentication Support for PANA October 2009
9.1. Normative References
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", RFC 5191, May 2008.
9.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-hokey-preauth-ps]
Ohba, Y. and G. Zorn, "Extensible Authentication Protocol
(EAP) Early Authentication Problem Statement",
draft-ietf-hokey-preauth-ps-09 (work in progress),
July 2009.
[802.21] IEEE, "Standard for Local and Metropolitan Area Networks:
Media Independent Handover Services", LAN MAN Standards
Committee of the IEEE Computer Society 802.21 2008.
Authors' Addresses
Yoshihiro Ohba
Toshiba Corporate Research and Development Center
1 Komukai-Toshiba-cho
Saiwai-ku, Kawasaki, Kanagawa 212-8582
Japan
Phone: +81 44 549 2230
Email: yoshihiro.ohba@toshiba.co.jp
Alper Yegin
Samsung
Istanbul
Turkey
Email: alper.yegin@yegin.org
Ohba & Yegin Expires April 14, 2010 [Page 8]
