draft-ietf-pana-preauth-05.txt   draft-ietf-pana-preauth-06.txt 
PANA Working Group Y. Ohba PANA Working Group Y. Ohba
Internet-Draft Toshiba Internet-Draft Toshiba
Intended status: Standards Track April 13, 2009 Intended status: Standards Track June 28, 2009
Expires: October 15, 2009 Expires: December 30, 2009
Pre-authentication Support for PANA Pre-authentication Support for PANA
draft-ietf-pana-preauth-05 draft-ietf-pana-preauth-06
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 October 15, 2009. This Internet-Draft will expire on December 30, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 41 skipping to change at page 3, line 41
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. Terminology 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 Serving Network: The access network to which the host is currently
access to the Internet/intranet. attached.
Candidate Network: An access network that is a potential target of Candidate Network: An access network that is a potential target of
host's handover. 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. provides network access authentication for a particular PaC.
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.
skipping to change at page 4, line 22 skipping to change at page 4, line 22
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.
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. For example, IEEE 802.21 [802.21] Information Service and
document. Command Service can be used for the PaC to discover the CPAA and the
CPAA to discover the PaC, respectively.
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 as to when the CPAA becomes start pre-authentication and the timing as to when the CPAA becomes
the SPAA. Such criteria can be implementation specific and thus are the SPAA. Such criteria can be implementation specific and thus are
outside the scope of this document. outside the 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 in a
'E' (prE-authentication) bit is defined in the PANA header. When similar way as normal authentication. A new 'E' (prE-authentication)
pre-authentication is performed, the 'E' (prE-authentication) bit of bit is defined in the PANA header. When pre-authentication is
PANA messages is set in order to indicate that this PANA run is for performed, the 'E' (prE-authentication) bit of PANA messages is set
pre-authentication. Use of pre-authentication is negotiated as in order to indicate that this PANA run is for pre-authentication.
follows. Use of pre-authentication is negotiated as 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 CPAA responds with a PANA-Auth-Request (PAR) message set. The CPAA responds with a PANA-Auth-Request (PAR) message
with the 'S' (Start) and 'E' (prE-authentication) bits set only if with the 'S' (Start) and 'E' (prE-authentication) bits set only if
it supports pre-authentication. Otherwise, the 'E' (prE- it supports pre-authentication. Otherwise, the 'E' (prE-
authentication) bit of the PAR message will be cleared according authentication) bit of the PAR message will be cleared according
to Section 6.2 of [RFC5191], which results in a negotiation to Section 6.2 of [RFC5191], which results in a negotiation
failure. failure.
skipping to change at page 9, line 32 skipping to change at page 9, line 32
[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]
Wu, W. and Y. Ohba, "EAP Pre-authentication Problem Ohba, Y. and G. Zorn, "Extensible Authentication Protocol
Statement", draft-ietf-hokey-preauth-ps-06 (work in (EAP) Early Authentication Problem Statement",
progress), March 2009. draft-ietf-hokey-preauth-ps-08 (work in progress),
June 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.
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. 7 change blocks. 
17 lines changed or deleted 23 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/