idnits 2.17.00 (12 Aug 2021) /tmp/idnits24607/draft-tschofenig-pana-framework-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 6 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 2) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (9 January 2003) is 7065 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) -- Missing reference section? '1' on line 683 looks like a reference -- Missing reference section? '2' on line 687 looks like a reference -- Missing reference section? '3' on line 691 looks like a reference -- Missing reference section? '4' on line 695 looks like a reference -- Missing reference section? '5' on line 698 looks like a reference -- Missing reference section? '6' on line 702 looks like a reference -- Missing reference section? '7' on line 705 looks like a reference -- Missing reference section? '8' on line 709 looks like a reference -- Missing reference section? '9' on line 712 looks like a reference -- Missing reference section? '10' on line 718 looks like a reference -- Missing reference section? '11' on line 724 looks like a reference -- Missing reference section? '12' on line 728 looks like a reference -- Missing reference section? '13' on line 732 looks like a reference -- Missing reference section? '14' on line 736 looks like a reference -- Missing reference section? '15' on line 740 looks like a reference -- Missing reference section? '16' on line 744 looks like a reference -- Missing reference section? '17' on line 748 looks like a reference -- Missing reference section? '18' on line 752 looks like a reference -- Missing reference section? '19' on line 756 looks like a reference -- Missing reference section? '20' on line 760 looks like a reference -- Missing reference section? '21' on line 763 looks like a reference -- Missing reference section? '22' on line 767 looks like a reference -- Missing reference section? '23' on line 771 looks like a reference -- Missing reference section? '24' on line 774 looks like a reference -- Missing reference section? '25' on line 778 looks like a reference -- Missing reference section? '27' on line 785 looks like a reference -- Missing reference section? '28' on line 788 looks like a reference -- Missing reference section? '29' on line 792 looks like a reference -- Missing reference section? '30' on line 796 looks like a reference -- Missing reference section? '31' on line 800 looks like a reference -- Missing reference section? '32' on line 804 looks like a reference -- Missing reference section? '33' on line 808 looks like a reference -- Missing reference section? '26' on line 782 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 35 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force PANA 3 Internet Draft H. Tschofenig 4 Siemens Corporate Technology 5 draft-tschofenig-pana-framework-00.txt 6 9 January 2003 7 Expires: July 2003 9 PANA Framework Issues 11 STATUS OF THIS MEMO 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 To view the list Internet-Draft Shadow Directories, see 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document discusses framework assumptions relevant to activities in 34 the PANA working group. It is tentative in nature and raises issues 35 regarding some assumptions made in the group. The aim of this draft is 36 therefore not to propose solutions instead issues are highlighted which 37 might require further consideration. 39 1 Introduction 41 This document discusses framework assumptions relevant to activities in 42 the PANA working group. It is tentative in nature and raises issues 43 regarding some assumptions made in the group. The aim of this draft is 44 therefore not to propose solutions instead issues are highlighted which 45 might require further consideration. 47 The document is organized as follows: 49 In Section 2 two basic scenarios are described which are differentiated 50 by their authorization procedure - which in this case is about charging. 51 The two scenarios are subscription-based access and alternative means of 52 access. Section 3 then considers a few possible results of a PANA 53 protocol execution. A few examples are listed with increasing order of 54 complexity. In Section 4 a few interesting requirements (in the view of 55 the author) are listed which might influence the outcome of a PANA 56 protocol. The author is aware of the fact that there should be a 57 separation between requirements, analysis and an actual protocol 58 development. However, requirements are not always (or not often) 59 orthogonal and a focus on some requirements (justified or not) might 60 heavily influence the shape of a later protocol design. Section 5 61 describes some building blocks which might be useful in a future 62 protocol. Some of the building blocks have already (individually) been 63 used in some protocol proposals. The building blocks are roughly aligned 64 in their order of execution - some of them can be omitted without 65 severely effecting the protocol (optional components). In Section 6 a 66 few thoughts on the relationship to mobility protocols (in particular 67 Mobile IP) are presented. Finally in Section 7 some conclusions derived 68 from the previous explanations are given. 70 2 Basic Scenarios 72 This section describes two scenarios for network access. The first 73 scenario is traditionally based on a relationship between the user and 74 his home network. The subscribed user uses his credentials in a AAA 75 scenario to dynamically establish a trust relationship between the home 76 network and the visited network. 78 Note that the term 'user' can also be replaced by some other entity for 79 which the authentication is performed (e.g. a device). The difference 80 between the two is (at the process of authentication and key exchange 81 itself) often marginal since it depends only on the used identifier 82 (e.g. NAI, Kerberos principal name, etc.). The usage of such an 83 identifier after authentication for authorization is often different. 84 Since an identity referring to a user provides some advantages compared 85 to a device, such as additional security, this term is used. The author 86 is, however, aware of the fact that some network access procedures used 87 today are based on device authentication. 89 2.1 Subscription-based access 91 Authentication of the user is typically provided to the home network 92 where the user is subscribed and credentials are available. It is 93 typically based on symmetric cryptography. The security relationships 94 are one-to-many, and asymmetric cryptography does not necessarily 95 provide advantages in key management in such a situation (although it 96 may provide other advantages, of course). In a mobile environment, the 97 performance advantages of symmetric cryptography are also important. The 98 message flow may involve many different visited networks, but an 99 established business relationship (e.g. roaming agreements) between the 100 visited and the home network may be assumed, hence accounting and 101 charging are feasible. 103 Without roaming the visited network and the home network coincide and 104 the end host is attached to the home network. This procedure simplifies 105 avoiding inter-realm communication. Some ISP scenarios are based on this 106 simplification. 108 2.2 Alternative means of access 110 In this scenario the user has no home network and therefore cannot 111 assume such for the purpose of authentication and authorization. Hence 112 authentication, authorization and payment is provided by other means 113 such as pre-paid cards, credit cards and other mechanisms (micro- and 114 macro-payment methods). Which protocol is required for the alternative 115 means of access case depends on the chosen payment protocol. These types 116 of environments are typically found in hot spots. 118 Additional information about a detailed problem description and protocol 119 exchanges at an abstract level is provided at [1]. 121 In the first scenario the visited network is given the assurance that 122 the indicated user is registered to a given home network and that the 123 home network provides a guarantee that the generated cost are covered. 124 In the second scenario the payment mechanism has to provide the 125 assurance that the end host is able to pay for the consumed resources. 126 Note that this does not necessarily require user authentication. But it 127 will typically require the transmission of payment-related confidential 128 data prior to completed authorization. This may imply that the 129 establishment of a security association is necessary to protect the 130 sending of this data before the user credential can be verified. This in 131 turn may necessitate the use of asymmetric cryptography to establish a 132 unilaterally authenticated tunnel. 134 3 Possible objectives of executing a PANA protocol 136 The execution of a PANA protocol is done for a particular purpose. We 137 try to list a few possible goals: 139 3.1 Transport of EAP messages 141 EAP is a container for a number of authentication and key exchange 142 protocol messages. In the past different transport mechanisms have been 143 proposed to exchange the EAP payloads between the end host and the AAA 144 attendant. For several link layers (e.g. IEEE 802) a transport mechanism 145 for EAP payloads has been standardized. But no such link layer 146 independent transport mechanism for EAP payloads is available although 147 it would clearly be very desirable. As a minimum, this would enable EAP- 148 based entity authentication independent of the link layer. Since the 149 selection of a transport mechanism seems to be an almost religious issue 150 it seems to be hard to agree on a particular mechanism. Especially the 151 different usage scenarios (wired, wireless, mobility, etc.) add 152 constraints. Nevertheless, it is seen as necessary that PANA comes up 153 with at least link layer independent transport mechanism for EAP 154 payloads. 156 3.2 Installation of filter rules 158 Installations of filter rules provides packet filtering behavior in 159 addition to entity authentication. The controlled/uncontrolled packet 160 forwarding, which was already described in the expired draft [2], 161 provides this functionality. Depending on the location of the EP(s) and 162 the PAA a protocol might be required to communicate the filter rules 163 from the PAA to the EP(s). A number of protocols have been investigated 164 in the Midcom working group for exactly this purpose. Since these 165 protocols are outside the scope of PANA only their relationship to the 166 Midcom working group is of interest; namely how to provide the 167 information which filter rules to install at which device. 169 The Midcom protocols would enable the use of temporary filter rules. The 170 purpose of installing such temporary filter rules is to prevent a threat 171 where an end host looses connectivity (for various reasons such as 172 mobility) and an adversary is able to reuse the installed filter rules 173 to transmit data traffic. Additionally a threat exists whereby an 174 adversary uses IP spoofing to inject packets on behalf of someone else. 175 The soft-state principle (i.e. installing filter rules which 176 automatically time out after some time) is important to prevent stale 177 state and possibly denial of service attacks. A more detailed threat 178 description can be found in [3] and with a slightly different focus in 179 [4]. Some of the threats described in the latter document are also 180 applicable in this context. 182 The requirement for disconnect indication aims to address these threats. 183 Various mechanisms are possible such as limiting the lifetime of the 184 filter rules (and possibly requiring continuous refreshes to keep them 185 in place), requiring continuous re-authentication and at the other 186 extreme requiring each packet to be protected. A small comment about the 187 relationship to existing work in the Midcom wg is given in Section A. 189 3.3 Session key distribution 190 Most EAP methods also provide the ability to establish a session key. 191 Session key derivation in EAP is still under discussion but it is worth 192 mentioning that the corresponding draft for carrying session keys via 193 the AAA infrastructure already exist. Protection for session keys 194 delivered in Diameter are provided by CMS [5]. The goal of session key 195 distribution is to provide the end host and the AAA attendant with a 196 unique and fresh session key after a successful AAA exchange (and in 197 this context based on a successful EAP authentication). The session key 198 for the AAA attendant is therefore most likely provided by the AAA 199 infrastructure whereas the end host obtains the session as a result of 200 the EAP authentication and key exchange procedure. As an alternative to 201 this procedure it is possible to establish a session key before client 202 authentication takes place. This approach is chosen by PANA over TLS [6] 203 and by the Secure Network Access Authentication proposal [7]. Care has 204 to be taken in these scenarios, however, to avoid man-in-the-middle 205 attacks. 207 Recent activities try to create a common framework for key derivation 208 which is described in [8] and might also be applicable for this context. 209 The key derivation and key transport procedure defined for EAP aims to 210 provide session keys for link layer devices (see Section 1 of [8] with 211 [9] and [10] as an example) but might also serve the purpose of creating 212 the pre-requisites for network layer protection (for example IPsec). One 213 building block, which is missing in this context, is a (generic) 214 mechanism for negotiation of algorithms and parameters, e.g. IPsec 215 security association parameters. 217 Given this functionality, which cannot be used by all EAP methods, the 218 question remains for what purpose these keys should be used (key 219 derivation) and where these keys have to be delivered (i.e. key 220 transport). Additionally the corresponding security association has to 221 be created which might either require third-party or two-party algorithm 222 and parameter negotiation. The difference between them has influence on 223 the performance similar to in-band vs. out-of-band protocols discussed 224 in other areas. 226 Additionally it should be mentioned that local re-authentication can be 227 provided when a session key is distributed and known to the local AAA 228 server. This local re-authentication might even use a different 229 authentication mechanism. In some scenarios such a procedure might 230 provide some performance advantages. Draft [11] describes some issues in 231 this context. 233 3.4 Providing secure network access 235 To grant access only for authenticated hosts/users can also be 236 accomplished by per-packet authentication. This prevents threats caused 237 by IP spoofing or threats which are caused due to mobility and a missing 238 disconnect indication. Such a per-packet authentication behavior 239 (including integrity protection) might also be of interest in a QoS 240 based environment with different QoS treated flows. The ability of 241 EAP/AAA to distribute session keys to establish an IPsec security 242 association between the end host and the first IP hop comes is an 243 example for this. In comparison to installed filter rules per-packet 244 authentication provides a more secure ability to associate each 245 individual IP packet with an authenticated user or host (which is 246 especially interesting for accounting but also of interest for 247 preventing unauthorized traffic to enter the network). 249 Another good reason for establishing such a security association is to 250 provide security for the first hop independently of the underlying link 251 layer technologies against various attacks on the wireless link. 252 Although there are good reasons for additionally providing link-layer 253 protection (at least for link layer signaling messages) there are many 254 reasons for providing the protection (possibly in addition) at the 255 network layer. The different arguments have already been extensively 256 discussed in various communities and will not be repeated in this 257 document. 259 A number of dead peer detection mechanisms have been proposed for 260 detecting 'disconnected' hosts which might be of interest for 261 performance reasons. The interested reader might want to take a look at 262 [12] as one promising proposal. There are, however, a number of other 263 proposals. 265 It is worth mentioning that an IPsec security association might be 266 useful for a number of other reasons such as micro-mobility, QoS 267 signaling, context transfer and other protocols. 269 3.5 Providing secure address configuration 271 There was often the discussion with what pre-requisites a PANA protocol 272 should start. Currently it is assumed that PANA is invoked after IP 273 address assignment (see [13]). There are, however, some threats which 274 address unprotected configuration messages in both stateful and 275 stateless address autoconfiguration. It is worth to mention that this 276 issue is still in discussion. 278 In addition to the discussion of how to protect the address 279 configuration procedure it might be necessary to consider how to obtain 280 some other configuration information like DNS servers etc. Since the 281 relationship to work done in the IPsec remote access working group is 282 apparent it might also be of interest to investigate secure address 283 bootstrapping mechanisms in this area. For securing address 284 configuration procedures [14] and [15] have been proposed. 286 It has to be clarified whether secure address configuration is 287 considered by the working group. 289 4 Discussion of PANA assumptions 291 This section aims to review some of the assumptions which appeared in 292 the PANA environment, and their implications. It is important to note 293 that certain assumption (e.g. the necessity of user identity 294 confidentiality) has far-reaching implications on the mechanisms 295 available to satisfy these assumptions. 297 User identity confidentiality: 299 Recently there has been an increased interest to keep the 300 identity used during the authentication process confidential. 301 It is important to make this requirement more precise. The 302 distinction between protection of the user identity against 303 passive attacks, i.e. eavesdropping, and active attacks, i.e. 304 modification or insertion of data, is crucial. For short, we 305 call the two different requirements active or passive user 306 identity confidentiality. Passive user identity 307 confidentiality can be provided by both, symmetric and 308 asymmetric cryptographic methods, whereas active user identity 309 confidentiality typically requires the use of asymmetric 310 cryptographic methods. Furthermore, it must be decided for 311 which peer (initiator or responder) active or passive user 312 identity confidentiality is required. Providing active user 313 identity protection for the initiator and the responder is not 314 possible (see e.g. the discussion around IKEv2. 316 Because of the involved entities in an EAP/AAA message 317 exchange it furthermore has to be investigated against which 318 entities this protection has to be provided (outsiders or 319 network nodes) and whether one should mandate identity 320 protection for a protocol in all environments. It should be 321 considered that pseudonyms or temporal identities, which are 322 also used to provide user identity confidentiality, might 323 require a different protection. Additionally there are 324 scenarios (for example described in [16] and in [3]) where the 325 connection between the end host and the access network is a 326 point-to-point link which makes eavesdropping quite difficult. 327 It should also be noted that elaborate user identity 328 protection schemes at higher layers are quite useless when the 329 user identity can be inferred from lower layer identities, 330 e.g. IP addresses or MAC addresses (like in IEEE 802.11). We 331 conclude that the cost of implementing a particular form of 332 user identity protection in the intended environment should be 333 carefully considered. 335 Ideally as a user it might be desirable to provide some form 336 of identity protection which only allows the home network to 337 learn the identity during authentication. In case of 338 alternative means of access described in Section 2 a pre-paid 339 service might not require user identity confidentiality since 340 the identity is temporary. 342 Tunneling Approach: 344 Support for legacy authentication mechanisms is often 345 mentioned as a justification for proposing TLS-based tunneling 346 approaches (in addition to user identity confidentiality). 347 Apart from the question what to call a legacy authentication 348 protocol it should be considered whether replacing the legacy 349 mechanisms which may not satisfy all desired security 350 requirements with a better mechanisms is preferable, given the 351 time horizon of the PANA working group. 353 Although this property is not a requirement it has some 354 implications for a PANA protocol. The following issues might 355 be of interest: 357 - At which entity should the tunnel be terminated? 359 - How should the end host decide where to terminate the 360 tunnel? 362 - Which protocol should be used to provide the tunnel? 364 - What are the performance implications caused by the tunnel? 366 - Why is it necessary to provide protection for all EAP 367 methods although only a few would benefit from the 368 established tunnel? 370 - Is the chosen tunnel approach secure against man-in-the- 371 middle attacks (see also below)? 373 On the other hand some protection of information exchanged 374 between the PaC and the PAA might be desirable such as EAP 375 messages other than those carrying authentication and key 376 exchange protocol payloads and content outside these EAP 377 messages (e.g. device identifier or filter rules, Mobile IP 378 related information, etc.). 380 If the tunnel is terminated in the access network then in a 381 global roaming case a public key infrastructure is introduced 382 since the end host must be able to authenticate the access 383 network based on the certificate received during the access 384 network to end host authentication. Additionally the end host 385 must be able to authorize the certificate of the access 386 network as one of a 'valid' access network provider. If the 387 certificate validation is not possible then an adversary could 388 impersonate an access network to act as a man-in-the-middle 389 adversary. As an alternative to a tunnel approach, one could 390 use mutual public key-based authentication executed between 391 the end host and the attached access network (e.g. TLS with 392 mutual authentication), but this would require the 393 distribution of certificates to clients, which would be much 394 more costly than simply having certificates for servers. 396 Disconnect indication: 398 Disconnect indication allows the to detect whenever an end 399 host has lost connectivity. As discussed in Section 3 the 400 properties of the useful mechanisms might show considerable 401 differences. Hence it might be interesting to determine 402 whether this property is really required and whether a 403 timer/lifetime negotiation is required. Periodic re- 404 authentication, dead peer detection mechanisms, secure 405 heartbeat (i.e. a challenge/response) protocol and others 406 might require a negotiation of timers/lifetime is required to 407 avoid an inappropriate large number (or low number) of 408 protocol exchanges. 410 5 Building Blocks 412 This section tries to list some of the possible building blocks which 413 might be required for a more advanced protocol. Which of these are 414 relevant for PANA is subject for further study. The individual parts 415 have been discussed at various sections. 417 Discovery of the PAA: In order to exchange the EAP payloads between 418 the PaC and the PAA it is necessary to discover the entity by 419 some mechanism. Using the first IP hop (default router) as the 420 PAA might simplify this discovery procedure. 422 Negotiation of authentication mechanisms: EAP supports a number of 423 different EAP methods and therefore it might be required to 424 agree on a specific mechanism. An unprotected negotiation 425 mechanism is supported in EAP. A secure negotiation procedure 426 for the GSS-API methods, which is also supported in EAP, is 427 described in [17]. 429 EAP message transport: Finally EAP messages have to be exchanged 430 between the various nodes using an agreed transport mechanism. 432 Several mechanisms have been proposed but further 433 investigation for the suitability might be required. Some 434 issues to consider are at least reliable message delivery with 435 fragmentation support. Fragmentation might for example be 436 required for some public key based authentication mechanisms. 437 In Section 4.5 of [13] congestion control is also mentioned as 438 a feature which must be supported. 440 Session key distribution and transport: As described in Section 3 441 it might be desirable to distribute a session key for 442 subsequent link layer or network layer protection. Session key 443 distribution within the Diameter protocol is already described 444 in [18]. Please note that Jesse Walker et. al. have recently 445 raised some concerns regarding the current description of the 446 key distribution in [19]. Various drafts mention the 447 possibility to provide key distribution to link layer devices. 449 Session key derivation: 451 EAP methods sometimes provide their own key derivation 452 procedure whereas others provide no key derivation at all. 453 Since the key derivation procedure heavily depends on the 454 protocol for which the session keys are used. Since the key 455 derivation procedure heavily depends on the protocol for which 456 the session keys are used it is beneficial to have a generic 457 session key derivation. Such a framework and many issues 458 associated with it are explained in [8]. If session key 459 derivation is only relevant for EAP methods then no further 460 actions need to be taken. If PANA defines additional 461 mechanisms or specific session key transport mechanisms then 462 further thoughts are required. In case of the tunneling 463 approach the man-in-the-middle attack problems discovered by 464 V. Niemi, K. Nyberg and N. Asokan, which are described in 465 [20], might require that the session keys of the two phases 466 are cryptographically combined as a possible solution to the 467 problem. Note, however, that EAP methods that do not 468 distribute a session key, which is particularly true for some 469 legacy authentication mechanisms, cannot be fixed by this 470 mechanism. From the problem description we can conclude that 471 the tunneling approaches introduced insecurity even for 472 previously secure authentication protocols (when used in this 473 environment). In Appendix B a small discussion of the 474 implications of the tunneling approaches is given. In a 475 recently published IETF draft [21] J. Puthenkulam et. al. also 476 describe the man-iin-the-middle attack in detail. 478 A few members in the CFGR working group are currently 479 investigating approaches for creating a unified session key 480 derivation framework. A previously published proposal by 481 Blumenthal [22] serves as one interesting input document. 483 SA establishment/negotiation: Distributing a session key is 484 unfortunately not sufficient for providing link layer or 485 network layer protection. Instead a security association is 486 required with information about algorithms and corresponding 487 parameters. These parameters need to be negotiated. 489 Filter rule installation: To allow network access after a 490 successful authentication and authorization step filter rules 491 might either be installed locally (via an API call, CLI, etc.) 492 or first need to be send to the corresponding device(s). 494 6 Mobility Implications 496 Mobility places some constraints on signaling protocols executed 497 (roundtrips, latency, etc.) and on how to combine different protocols 498 (in-band signaling) to be even more efficient. Mobile IP ([23] and [24]) 499 is an example of such a protocol where signaling messages are 500 transmitted immediately after roaming. Hence it was logical step to 501 combine the network access procedures using AAA (which are also executed 502 immediately after roaming) with mobility signaling. [25] explains such a 503 procedure for Mobile IP (IPv4) and [26]/[27] envision a similar approach 504 for IPv6. 506 Although these proposals use a custom security mechanisms for 507 authentication, key exchange and for protection of protecting of the 508 mobility payloads [27] mentions the use of EAP. Replacing the custom 509 security mechanism with EAP would allow different authentication and key 510 exchange protocols to be used. Since the payloads used by Mobile IP, 511 which are ideally carried with the same messages (i.e. in-band), must be 512 protected, the following issues require further thoughts: 514 · How are Mobile IP payloads protected? Using the custom security 515 protection defined in ([2] or [27]) the MIP payloads are simply 516 included by the keyed message digest calculation among other 517 fields. If EAP is used instead of this custom security mechanism, 518 which key is used for the protection of the payloads? 520 · Is the above scheme of payload protecting extensible to all EAP 521 methods? For the author it seems that this is not fully the case 522 if we consider secure password based protocols. These protocols 523 require that the message payloads where the password is 524 cryptographically applied is not vulnerable to dictionary 525 attacks. This is mainly achieved by either encrypting the 526 password with a random component or vice versa. If known 527 plaintext (e.g. Mobile IP parameter) is encrypted with the 528 password then this property is destroyed. 530 · Which other payloads (apart from Mobile IP) would benefit from 531 in-band signaling in AAA (and also require protection)? 533 It is therefore up to the working group to decide whether PANA should be 534 designed in such an extensible way to include these (and possibly other) 535 parameters. Mobility (especially seamless mobility) clearly places some 536 performance restrictions to a PANA protocol. Hence it might not be able 537 to run an 'arbitrary' number of roundtrip between the end host and a 538 possibly far distant home network before transmitting mobility related 539 signaling messages. 541 7 Conclusion 543 This draft aims to show the relationship to other protocols which are 544 relevant for PANA. It therefore tries to address the question what the 545 result of a PANA protocol exchange should be. In the past there has been 546 some confusion about the working direction of the group. In Section 3 547 possible outcomes of a PANA protocol execution are presented with 548 various degrees of complexity. Depending on the focus of the group the 549 working group may try to achieve (the given list might ): 551 · Pure EAP message transport 553 · EAP message transport with installation of filter rules 555 · Full secure network access protocol 557 The working group seems to focus on EAP as a container for 558 authentication and key exchange protocols. Hence similar protocols such 559 as SASL are not considered in this document. 561 It is possible that a single protocol (without optional components) 562 might not completely fit in all environments. 564 8 Security Considerations 566 This document addresses a number of security issues but no protocol is 567 proposed. Hence as such no separate security considerations are 568 presented. 570 9 Acknowledgements 572 I would like to thank (in alphabetical order) Wolfgang Buecker, Jorge 573 Cuellar, Guenther Horn, Dirk Kroeselberg, Yoshihiro Ohba and Basavaraj 574 Patil for their comments to this document. Additionally I would like to 575 thank all members of the EU funded project Shaman for their fruitful 576 discussions. I would like to particularly thank the following WP1 Shaman 577 members: Krister Boman, Fredrik Lindholm, Valtteri Niemi, Kaisa Nyberg, 578 Chris Mitchell, Scarlet Schwiderski-Grosche, Heiko Knospe, Tobias 579 Martin, Joachim Schaaf, Peter Windirsch and Peter Howard. 581 Finally, I would like to thank Alper Yegin for encouraging me to write 582 this document and for his comments. 584 A Relationship to filter rule installation 586 The goal of establishing filter rules at some devices seems to be 587 similar to the activities in the Midcom working group. Hence it might be 588 of interest to look at some of the proposals and additionally at drafts 589 published in this context such as TIST [28], which is based on RSVP, or 590 a more recent approach CASP-Midcom [29], which reuses the same ideas 591 based on the CASP protocol [30]. These two proposals allow an end host 592 to communicate filter rules to devices (more or less) along the data 593 path. A mechanism for discovering these devices is also provided by 594 these proposals. There are, however, differences between the work done 595 in the Midcom and the NSIS group and the considerations made for PANA. 596 First, filter rules are installed for particular message flows only 597 (typically described by a 5-tuple) and not to grant entire network 598 access. Additionally at least [28] has no means to transport EAP 599 messages and in [29] only the basic idea is mentioned without 600 elaborating the details. Second, for these two protocols there must be 601 a mechanism to restrict the filter rule installation only at the edge 602 devices or within the local network only. Without such a mechanism the 603 messages travel towards the given destination address. Ideas for such a 604 scoped/localized signaling message exchange are already considered but 605 not fully investigated. Additionally it must be mentioned that the 606 signaling procedure in these two protocols is heavily based on the 607 assumption of topology insensitivity. This also causes filter rules to 608 be uni-directional. 610 B Tunneling Implications 612 In Section 5 the man-in-the-middle attack is described in context of the 613 session key derivation and tunneling approaches. As a solution of the 614 problem the documents [20] and [21] suggest to cryptographically bind 615 the session keys of the two phases, the TLS session key and the session 616 key deriving from the EAP method, to each other. Afterwards the 617 knowledge of this derived session key has to be proven either implicitly 618 or explicitly. In case of an implicit binding the combined session key 619 is used to protect the communication between the two end points. This 620 approach obviously requires that the derived session key is used 621 afterwards for data protection. In order to provide the knowledge of a 622 combined session key for an explicit binding an additional message 623 exchange is required. In Section 4 of [20] an example of such a 624 cryptographic explicit binding is described which is based on a keyed 625 message digest. Since these tunneling approaches have been introduced to 626 protect legacy authentication mechanisms, which in some cases do not 627 derive a session key as part of the authentication process, the question 628 remains how such a cryptographic binding can be established in these 629 cases. In [20] a 'binding agent' is introduced which combines the 630 session of the tunnel (for example the TLS established session key) and 631 the long-term secret used for the EAP method in case that no session key 632 is created. 634 Existing tunneling proposals use two different types of tunnels: 636 Tunnel endpoint identical with EAP end point: With this tunnel the 637 EAP endpoint and the tunnel endpoint are co-located. This type 638 of tunnel is used with EAP-TTLS [31], PEAP [32] and in PIC 639 [33]. If the client authentication mechanism does not create a 640 session key then the long-term secret between the user and the 641 authentication server (e.g. AAAH) can be used by the binding 642 agent to derive a new session key. To securely deliver the 643 user's long-term secret to the binding agent might not be a 644 serious problem since the endpoints are likely to be in the 645 same administrative domain. 647 Tunnel endpoint not identical with EAP end point: With this tunnel 648 the EAP endpoint is not the same as the tunnel end point of 649 the tunnel. This type of tunnel is used by the PANA over TLS 650 proposal [6] and by the Secure Network Access Authentication 651 proposal [7]. In these proposals the tunnel end point is 652 established between the PaC and the PAA to protect the EAP 653 message exchange between these two nodes. The EAP messages 654 exchanged by the protected tunnel are then possibly forwarded 655 to a backend server (e.g. to a AAAH server) using a AAA 656 infrastructure. If a mobile node roams to a new network then 657 the tunnel (i.e. TLS tunnel) is terminated at the PAA and the 658 EAP messages travel all the way back to the home AAA server. 659 In order to use the same procedure as above the binding agent 660 needs to have both keys (the session key established with the 661 TLS tunnel and the user's long term secret). It would be 662 problematic to transfer the user's long-term secret to the 663 visited network where the TLS tunnel terminates. Hence one 664 possibility is to transfer the TLS established session key to 665 the end point of the EAP method. After the binding agent at 666 the AAAH server derives the combined session key it is 667 transferred back to the tunnel end point in the visited 668 network (i.e. to the PAA) since it might be used to secure the 669 data traffic between the PaC and some node in the visited 670 network. 672 C Authors' Address 674 Hannes Tschofenig 675 Siemens Corporate Technology 676 Otto-Hahn-Ring 6 677 81739 Munich 678 Germany 679 EMail: Hannes.Tschofenig@siemens.com 681 D Bibliography 683 [1] H. Knospe and S. Schwiderski-Grosche, "Online payment for access to 684 heterogeneous mobile networks," in IST Mobile and Wireless 685 Telecommunications Summit 2002 , 2002. 687 [2] P. Flykt, C. Perkins, and T. Eklund, "AAA for IPv6 network access," 688 Internet Draft, Internet Engineering Task Force, Mar. 2002. Work in 689 progress. 691 [3] M. Parthasarathy, "Pana threat analysis and security requirements," 692 internet draft, Internet Engineering Task Force, 2002. Work in 693 progress. 695 [4] H. Tschofenig, "Nsis threats," internet draft, Internet Engineering 696 Task Force, 2002. Work in progress. 698 [5] P. Calhoun, S. Farrell, and W. Bulley, "Diameter CMS security 699 application," Internet Draft, Internet Engineering Task Force, Mar. 700 2002. Work in progress. 702 [6] Y. Ohba, S. Baba, and S. Das, "Pana over tls," Internet Draft, 703 Internet Engineering Task Force, 2002. Work in progress. 705 [7] D. Forsberg and J. Rajahalme, "Secure network access authentication 706 (senaa)," Internet Draft, Internet Engineering Task Force, 2002. Work 707 in progress. 709 [8] B. Aboba, "The EAP session key problem," Internet Draft, Internet 710 Engineering Task Force, Feb. 2002. Work in progress. 712 [9] I. D. 802.11i/D2, "Draft supplement to standard for 713 telecommunications and information exchange between systems - lan/man 714 specific requirements - part 11: Wireless medium access control (mac) 715 and physical layer (phy) specifications: Specification for enhanced 716 security," tech. rep., 2001. 718 [10] I. S. 802.11-1997, "Information technology - telecommunications and 719 information exchange between systems - local and metropolitan area 720 networks - specific requirements part 11: Wireless lan medium access 721 control (mac) and physical layer (phy) specifications," tech. rep., 722 1997. 724 [11] S. Faccin and F. Le, "AAA local security association (LSA): The 725 temporary shared key (TSK)," Internet Draft, Internet Engineering Task 726 Force, July 2001. Work in progress. 728 [12] G. Huang, S. Beaulieu, and D. Rochefort, "A traffic-based method of 729 detecting dead ike peers," internet draft, Internet Engineering Task 730 Force, 2002. Work in progress. 732 [13] A. Yegin, R. Penno, et al. , "Protocol for carrying authentication 733 for network access (PANA)requirements and terminology," Internet Draft, 734 Internet Engineering Task Force, July 2002. Work in progress. 736 [14] B. Patel, B. Aboba, S. Kelly, and V. Gupta, "DHCPv4 configuration 737 of IPSEC tunnel mode," Internet Draft, Internet Engineering Task Force, 738 May 2001. Work in progress. 740 [15] D. Dukes and R. Pereira, "The ISAKMP configuration method," 741 Internet Draft, Internet Engineering Task Force, Oct. 2001. Work in 742 progress. 744 [16] Y. Ohba et al. , "Problem space and usage scenarios for PANA," 745 Internet Draft, Internet Engineering Task Force, June 2002. Work in 746 progress. 748 [17] E. Baize and D. Pinkas, "The simple and protected GSS-API 749 negotiation mechanism," RFC 2478, Internet Engineering Task Force, Dec. 750 1998. 752 [18] E. Gustafsson, W. Bulley, A. Rubens, J. Haag, G. Zorn, and D. 753 Spence, "Diameter NASREQ application," Internet Draft, Internet 754 Engineering Task Force, Mar. 2002. Work in progress. 756 [19] J. Walker, R. Housley, and N. Cam-Winget, "AAA key distribution," 757 Internet Draft, Internet Engineering Task Force, Apr. 2002. Work in 758 progress. 760 [20] N. Asokan, V. Niemi, and K. Nyberg, "Man-in-the-middle in tunnelled 761 authentication," in http://eprint.iacr.org/2002/163/ , 2002. 763 [21] J. Puthenkulam, V. Lortz, A. Palekar, D. Simon, and B. Aboba, "The 764 compound authentication binding problem," internet draft, Internet 765 Engineering Task Force, 2002. Work in progress. 767 [22] U. Blumenthal, "Secure session key generation. creating PRF from 768 MAC function," Internet Draft, Internet Engineering Task Force, July 769 2002. Work in progress. 771 [23] C. Perkins and Ed, "IP mobility support for IPv4," RFC 3220, 772 Internet Engineering Task Force, Jan. 2002. 774 [24] D. Johnson, C. Perkins, and J. Arkko, "Mobility support in IPv6," 775 Internet Draft, Internet Engineering Task Force, July 2002. Work in 776 progress. 778 [25] C. Perkins and E. Gustafsson, "AAA registration keys for mobile 779 IP," Internet Draft, Internet Engineering Task Force, Mar. 2002. Work 780 in progress. 782 [26] F. Dupont et al. , "AAA for mobile IPv6," Internet Draft, Internet 783 Engineering Task Force, Nov. 2001. Work in progress. 785 [27] S. Faccin et al. , "Diameter mobile IPv6 application," Internet 786 Draft, Internet Engineering Task Force, Nov. 2001. Work in progress. 788 [28] M. Shore, "The TIST (topology-insensitive service traversal) 789 protocol," Internet Draft, Internet Engineering Task Force, May 2002. 790 Work in progress. 792 [29] H. Tschofenig and H. Schulzrinne, "A firewall/nat traversal client 793 for casp," internet draft, Internet Engineering Task Force, 2002. Work 794 in progress. 796 [30] H. Schulzrinne, H. Tschofenig, X. Fu, J. Eisl, and R. Hancock, 797 "Casp - cross-application signaling protocol," internet draft, Internet 798 Engineering Task Force, 2002. Work in progress. 800 [31] P. Funk and S. Blake-Wilson, "EAP tunneled TLS authentication 801 protocol (EAP-TTLS)," Internet Draft, Internet Engineering Task Force, 802 Mar. 2002. Work in progress. 804 [32] H. Andersson, S. Josefsson, G. Zorn, et al. , "Protected 805 extensible authentication protocol (PEAP)," Internet Draft, Internet 806 Engineering Task Force, Feb. 2002. Work in progress. 808 [33] Y. Sheffer, H. Krawczyk, and B. Aboba, "PIC, a pre-IKE credential 809 provisioning protocol," Internet Draft, Internet Engineering Task Force, 810 Feb. 2002. Work in progress.