draft-ietf-pana-preauth-06.txt   draft-ietf-pana-preauth-07.txt 
PANA Working Group Y. Ohba PANA Working Group Y. Ohba
Internet-Draft Toshiba Internet-Draft Toshiba
Intended status: Standards Track June 28, 2009 Intended status: Standards Track A. Yegin
Expires: December 30, 2009 Expires: April 14, 2010 Samsung
October 11, 2009
Pre-authentication Support for PANA Pre-authentication Support for PANA
draft-ietf-pana-preauth-06 draft-ietf-pana-preauth-07
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 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 December 30, 2009. This Internet-Draft will expire on April 14, 2010.
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 2, line 13 skipping to change at page 2, line 14
a PANA security association between a PANA client in one access a PANA security association between a PANA client in one access
network and a PANA authentication agent in another access network to network and a PANA authentication agent in another access network to
which the PANA client may move. 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Pre-authentication Procedure . . . . . . . . . . . . . . . . . 4 3. Pre-authentication Procedure . . . . . . . . . . . . . . . . . 4
4. PANA Extensions . . . . . . . . . . . . . . . . . . . . . . . . 7 4. PANA Extensions . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
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 from one access network to mobile device and is capable of moving from one access network to
another while running its applications, it is critical for the PaC to another while running its applications, it is critical for the PaC to
perform a handover seamlessly without degrading the performance of perform a handover seamlessly without degrading the performance of
the applications during the handover period. When the handover the applications during the handover period. When the handover
skipping to change at page 4, line 21 skipping to change at page 4, line 21
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.
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 to discover a CPAA. IEEE
other. For example, IEEE 802.21 [802.21] Information Service and 802.21 [802.21] Information Service is used for the default CPAA
Command Service can be used for the PaC to discover the CPAA and the discovery mechanism.
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 in a Pre-authentication is initiated by a PaC in a similar way as normal
similar way as normal authentication. A new 'E' (prE-authentication) authentication. A new 'E' (prE-authentication) bit is defined in the
bit is defined in the PANA header. When pre-authentication is PANA header. When pre-authentication is performed, the 'E' (prE-
performed, the 'E' (prE-authentication) bit of PANA messages is set authentication) bit of PANA messages is set in order to indicate that
in order to indicate that this PANA run is for pre-authentication. this PANA run is for pre-authentication. Use of pre-authentication
Use of pre-authentication is negotiated as follows. 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.
o When a CPAA initiates pre-authentication, it sends a PAR message
with the 'S' (Start) and 'E' (prE-authentication) bits set. The
PaC responds with a PANA-Auth-Answer (PAN) 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 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 successfully negotiated on performing o Once the PaC and CPAA have successfully negotiated on performing
pre-authentication using the 'S' (Start) and 'E' (prE- pre-authentication using the 'S' (Start) and 'E' (prE-
authentication) bits, the subsequent PANA messages exchanged authentication) bits, the subsequent PANA messages exchanged
between them MUST have the 'E' (prE-authentication) bit set until between them MUST have the 'E' (prE-authentication) bit set until
CPAA becomes SPAA of the PaC. The PaC may conduct this exchange 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 with more than one CPAA. If the PaC and CPAA have failed to
negotiate on performing pre-authentication, the PaC or CPAA that negotiate on performing pre-authentication, the PaC or CPAA that
sent a message with both the 'S' (Start) and 'E' (prE- sent a message with both the 'S' (Start) and 'E' (prE-
authentication) bits set MUST discard the message received from authentication) bits set MUST discard the message received from
the peer with 'S' (Start) bit set and the 'E' (prE-authentication) the peer with 'S' (Start) bit set and the 'E' (prE-authentication)
skipping to change at page 5, line 30 skipping to change at page 5, line 21
When a CPAA of the PaC becomes the SPAA due to, e.g., movement of the 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- PaC, the PaC informs the PAA of the change using PANA-Notification-
Request (PNR) and PANA-Notification-Answer (PNA) messages with the Request (PNR) and PANA-Notification-Answer (PNA) messages with the
'P' (Ping) bit set and the 'E' (prE-authentication) bit cleared. The 'P' (Ping) bit set and the 'E' (prE-authentication) bit cleared. The
'E' (prE-authentication) bit MUST be cleared in subsequent PANA 'E' (prE-authentication) bit MUST be cleared in subsequent PANA
messages. messages.
The PANA session between the PaC and a CPAA is deleted by entering The PANA session between the PaC and a CPAA is deleted by entering
the termination phase of the PANA protocol. the termination phase of the PANA protocol.
Example call flows for PaC-initiated pre-authentication and PAA- Example call flows for pre-authentication is shown in Figure 1. Note
initiated pre-authentication are shown in Figure 1 and Figure 2, that EAP authentication is performed over PAR and PAN exchanges.
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 |
skipping to change at page 6, line 37 skipping to change at page 6, line 37
+----------+ | +----------+ |
| PNR w/ 'P' bit set and w/o 'E' bit set | | PNR w/ 'P' bit set and w/o 'E' bit set |
|------------------------------------------------>| |------------------------------------------------>|
| +-----------------+ | +-----------------+
| |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: Pre-authentication Call Flow
PaC CPAA
| |
| +------------------+
| |Pre-authentication|
| |trigger |
| +------------------+
| 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 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|
skipping to change at page 8, line 22 skipping to change at page 7, line 22
Backward compatibility between a PANA entity that does not support Backward compatibility between a PANA entity that does not support
the pre-authentication extension and another PANA entity that the pre-authentication extension and another PANA entity that
supports the pre-authentication extension is maintained as follows. supports the pre-authentication extension is maintained as follows.
When a PaC that supports the pre-authentication extension initiates When a PaC that supports the pre-authentication extension initiates
PANA pre-authentication by sending a PCI message with the 'E' (prE- 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) bit set to a PAA that does not support the pre-
authentication extension, the PAA will ignore the E-bit according to 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 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 authentication attempt. As a result, the PaC will receive a PAR
message with the 'E' (prE-authentication) bit cleared. message with the 'E' (prE-authentication) bit cleared. In this case,
the negotiation on the use of pre-authentication will fail and
Similarly, when a PAA that supports the pre-authentication extension eventually the PANA session will be terminated as described in
initiates PANA pre-authentication by sending a PAR message with the Section Section 3.
'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, an access network may be configured across multiple access networks, an access network may be configured
to allow or disallow PANA messages from a set of access networks. to allow or disallow PANA messages from a set of access networks.
When pre-authentication is initiated by CPAA, it is possible that
multiple CPAAs simultaneously initiate pre-authentication for the
same PaC. In order to avoid possible resource consumption attacks on
the PaC caused by an attacker initiating pre-authentication for the
PaC by changing source addresses, the PaC SHOULD limit the maximum
number of CPAAs allowed to communicate.
7. IANA Considerations 7. IANA Considerations
As described in Section 4, bit 6 of the Flags field of the PANA 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) Header needs to be assigned by IANA for the 'E' (prE-authentication)
bit. bit.
8. Acknowledgments 8. Acknowledgments
The author would like to thank Alper Yegin, Basavaraj Patil, Ashutosh The author would like to thank Basavaraj Patil, Ashutosh Dutta,
Dutta, Julien Bournelle, Sasikanth Bharadwaj, Subir Das, Rafa Marin Julien Bournelle, Sasikanth Bharadwaj, Subir Das, Rafa Marin Lopez,
Lopez, Lionel Morand, Victor Fajardo, Glen Zorn and Qin Wu for their Lionel Morand, Victor Fajardo, Glen Zorn and Qin Wu for their support
support and valuable feedback. 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.
skipping to change at page 9, line 34 skipping to change at page 8, line 18
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. and G. Zorn, "Extensible Authentication Protocol Ohba, Y. and G. Zorn, "Extensible Authentication Protocol
(EAP) Early Authentication Problem Statement", (EAP) Early Authentication Problem Statement",
draft-ietf-hokey-preauth-ps-08 (work in progress), draft-ietf-hokey-preauth-ps-09 (work in progress),
June 2009. July 2009.
[802.21] IEEE, "Standard for Local and Metropolitan Area Networks: [802.21] IEEE, "Standard for Local and Metropolitan Area Networks:
Media Independent Handover Services", LAN MAN Standards Media Independent Handover Services", LAN MAN Standards
Committee of the IEEE Computer Society 802.21 2008. Committee of the IEEE Computer Society 802.21 2008.
Author's Address Authors' Addresses
Yoshihiro Ohba Yoshihiro Ohba
Toshiba America Research, Inc. Toshiba Corporate Research and Development Center
1 Telcordia Drive 1 Komukai-Toshiba-cho
Piscateway, NJ 08854 Saiwai-ku, Kawasaki, Kanagawa 212-8582
USA Japan
Phone: +1 732 699 5305 Phone: +81 44 549 2230
Email: yohba@tari.toshiba.com Email: yoshihiro.ohba@toshiba.co.jp
Alper Yegin
Samsung
Istanbul
Turkey
Email: alper.yegin@yegin.org
 End of changes. 17 change blocks. 
100 lines changed or deleted 41 lines changed or added

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