idnits 2.17.1 draft-ietf-pana-preauth-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 11, 2009) is 5309 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-hokey-preauth-ps-09 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PANA Working Group Y. Ohba 3 Internet-Draft Toshiba 4 Intended status: Standards Track A. Yegin 5 Expires: April 14, 2010 Samsung 6 October 11, 2009 8 Pre-authentication Support for PANA 9 draft-ietf-pana-preauth-07 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 14, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document defines an extension to the Protocol for carrying 48 Authentication for Network Access (PANA) for proactively establishing 49 a PANA security association between a PANA client in one access 50 network and a PANA authentication agent in another access network to 51 which the PANA client may move. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Specification of Requirements . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Pre-authentication Procedure . . . . . . . . . . . . . . . . . 4 59 4. PANA Extensions . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 7 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 63 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 66 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Introduction 71 The Protocol for carrying Authentication for Network Access (PANA) 72 [RFC5191] carries EAP messages between a PaC (PANA Client) and a PAA 73 (PANA Authentication Agent) in the access network. If the PaC is a 74 mobile device and is capable of moving from one access network to 75 another while running its applications, it is critical for the PaC to 76 perform a handover seamlessly without degrading the performance of 77 the applications during the handover period. When the handover 78 requires the PaC to establish a PANA session with the PAA in the new 79 access network, the signaling to establish the PANA session should be 80 completed as fast as possible. See [I-D.ietf-hokey-preauth-ps] for 81 the handover latency requirements. 83 This document defines an extension to the PANA protocol [RFC5191] 84 used for proactively executing EAP authentication and establishing a 85 PANA SA (Security Association) between a PaC in an access network and 86 a PAA in another access network to which the PaC may move. The 87 extension to the PANA protocol is designed to realize direct pre- 88 authentication defined in [I-D.ietf-hokey-preauth-ps]. How to 89 realize authorization and accounting with the use of the pre- 90 authentication extension is out of the scope of this document. 92 1.1. Specification of Requirements 94 In this document, several words are used to signify the requirements 95 of the specification. These words are often capitalized. The key 96 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 97 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 98 are to be interpreted as described in [RFC2119]. 100 2. Terminology 102 The following terms are used in this document in addition to the 103 terms defined in [RFC5191]. 105 Serving Network: The access network to which the host is currently 106 attached. 108 Candidate Network: An access network that is a potential target of 109 host's handover. 111 Serving PAA (SPAA): A PAA that resides in the serving network and 112 provides network access authentication for a particular PaC. 114 Candidate PAA (CPAA): A PAA that resides in a candidate network to 115 which the PaC may move. A CPAA for a particular PaC may be a SPAA 116 for another PaC. 118 Pre-authentication: Pre-authentication refers to EAP pre- 119 authentication and defined as the utilization of EAP to pre- 120 establish EAP keying material on an authenticator prior to arrival 121 of the peer at the access network served by that authenticator 122 [I-D.ietf-hokey-preauth-ps]. In this draft, EAP pre- 123 authentication is performed between a PaC and a CPAA. 125 3. Pre-authentication Procedure 127 A PaC that supports pre-authentication may establish a PANA session 128 for each CPAA. 130 There may be several mechanisms for a PaC to discover a CPAA. IEEE 131 802.21 [802.21] Information Service is used for the default CPAA 132 discovery mechanism. 134 There may be a number of criteria for CPAA selection, the timing to 135 start pre-authentication and the timing as to when the CPAA becomes 136 the SPAA. Such criteria can be implementation specific and thus are 137 outside the scope of this document. 139 Pre-authentication is initiated by a PaC in a similar way as normal 140 authentication. A new 'E' (prE-authentication) bit is defined in the 141 PANA header. When pre-authentication is performed, the 'E' (prE- 142 authentication) bit of PANA messages is set in order to indicate that 143 this PANA run is for pre-authentication. Use of pre-authentication 144 is negotiated as follows. 146 o When a PaC initiates pre-authentication, it sends a PANA-Client- 147 Initiation (PCI) message with the 'E' (prE-authentication) bit 148 set. The CPAA responds with a PANA-Auth-Request (PAR) message 149 with the 'S' (Start) and 'E' (prE-authentication) bits set only if 150 it supports pre-authentication. Otherwise, the 'E' (prE- 151 authentication) bit of the PAR message will be cleared according 152 to Section 6.2 of [RFC5191], which results in a negotiation 153 failure. 155 o Once the PaC and CPAA have successfully negotiated on performing 156 pre-authentication using the 'S' (Start) and 'E' (prE- 157 authentication) bits, the subsequent PANA messages exchanged 158 between them MUST have the 'E' (prE-authentication) bit set until 159 CPAA becomes SPAA of the PaC. The PaC may conduct this exchange 160 with more than one CPAA. If the PaC and CPAA have failed to 161 negotiate on performing pre-authentication, the PaC or CPAA that 162 sent a message with both the 'S' (Start) and 'E' (prE- 163 authentication) bits set MUST discard the message received from 164 the peer with 'S' (Start) bit set and the 'E' (prE-authentication) 165 bit cleared, which will eventually result in PANA session 166 termination. 168 When a CPAA of the PaC becomes the SPAA due to, e.g., movement of the 169 PaC, the PaC informs the PAA of the change using PANA-Notification- 170 Request (PNR) and PANA-Notification-Answer (PNA) messages with the 171 'P' (Ping) bit set and the 'E' (prE-authentication) bit cleared. The 172 'E' (prE-authentication) bit MUST be cleared in subsequent PANA 173 messages. 175 The PANA session between the PaC and a CPAA is deleted by entering 176 the termination phase of the PANA protocol. 178 Example call flows for pre-authentication is shown in Figure 1. Note 179 that EAP authentication is performed over PAR and PAN exchanges. 181 PaC CPAA 182 | | 183 +------------------+ | 184 |Pre-authentication| | 185 |trigger | | 186 +------------------+ | 187 | PCI w/'E' bit set | 188 |------------------------------------------------>| 189 | PAR w/'S' and 'E' bits set | 190 |<------------------------------------------------| 191 | PAN w/'S' and 'E' bits set | 192 |------------------------------------------------>| 193 | PAR-PAN exchange w/'E' bit set | 194 |<----------------------------------------------->| 195 | PAR w/'C' and 'E' bits set | 196 |<------------------------------------------------| 197 | PAN w/'C' and 'E' bits set | 198 |------------------------------------------------>| 199 . . . 200 . . . 201 +----------+ | 202 | Movement | | 203 +----------+ | 204 | PNR w/ 'P' bit set and w/o 'E' bit set | 205 |------------------------------------------------>| 206 | +-----------------+ 207 | |CPAA becomes SPAA| 208 | +-----------------+ 209 | PNA w/ 'P' bit set and w/o 'E' bit set | 210 |<------------------------------------------------| 211 | | 213 Figure 1: Pre-authentication Call Flow 215 4. PANA Extensions 217 A new 'E' (prE-authentication) bit is defined in Flags field of PANA 218 header as follows. 220 0 1 221 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 |R S C A P I E r r r r r r r r r| 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 E(PrE-authentication) When pre-authentication is performed, the 'E' 226 (prE-authentication) bit of PANA messages is set in order to 227 indicate whether this PANA run is for pre-authentication. The 228 exact usage of this bit is described in Section 3. This bit is to 229 be assigned by IANA. 231 5. Backward Compatibility 233 Backward compatibility between a PANA entity that does not support 234 the pre-authentication extension and another PANA entity that 235 supports the pre-authentication extension is maintained as follows. 237 When a PaC that supports the pre-authentication extension initiates 238 PANA pre-authentication by sending a PCI message with the 'E' (prE- 239 authentication) bit set to a PAA that does not support the pre- 240 authentication extension, the PAA will ignore the E-bit according to 241 Section 6.2 of [RFC5191], and try to process the message as a normal 242 authentication attempt. As a result, the PaC will receive a PAR 243 message with the 'E' (prE-authentication) bit cleared. In this case, 244 the negotiation on the use of pre-authentication will fail and 245 eventually the PANA session will be terminated as described in 246 Section Section 3. 248 6. Security Considerations 250 Since the mechanism described in this document is designed to work 251 across multiple access networks, an access network may be configured 252 to allow or disallow PANA messages from a set of access networks. 254 7. IANA Considerations 256 As described in Section 4, bit 6 of the Flags field of the PANA 257 Header needs to be assigned by IANA for the 'E' (prE-authentication) 258 bit. 260 8. Acknowledgments 262 The author would like to thank Basavaraj Patil, Ashutosh Dutta, 263 Julien Bournelle, Sasikanth Bharadwaj, Subir Das, Rafa Marin Lopez, 264 Lionel Morand, Victor Fajardo, Glen Zorn and Qin Wu for their support 265 and valuable feedback. 267 9. References 268 9.1. Normative References 270 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 271 Yegin, "Protocol for Carrying Authentication for Network 272 Access (PANA)", RFC 5191, May 2008. 274 9.2. Informative References 276 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 277 Requirement Levels", BCP 14, RFC 2119, March 1997. 279 [I-D.ietf-hokey-preauth-ps] 280 Ohba, Y. and G. Zorn, "Extensible Authentication Protocol 281 (EAP) Early Authentication Problem Statement", 282 draft-ietf-hokey-preauth-ps-09 (work in progress), 283 July 2009. 285 [802.21] IEEE, "Standard for Local and Metropolitan Area Networks: 286 Media Independent Handover Services", LAN MAN Standards 287 Committee of the IEEE Computer Society 802.21 2008. 289 Authors' Addresses 291 Yoshihiro Ohba 292 Toshiba Corporate Research and Development Center 293 1 Komukai-Toshiba-cho 294 Saiwai-ku, Kawasaki, Kanagawa 212-8582 295 Japan 297 Phone: +81 44 549 2230 298 Email: yoshihiro.ohba@toshiba.co.jp 300 Alper Yegin 301 Samsung 302 Istanbul 303 Turkey 305 Email: alper.yegin@yegin.org