idnits 2.17.1 draft-ietf-hokey-reauth-ps-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 492. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 503. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 510. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 516. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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 (January 16, 2007) is 6310 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-16 == Outdated reference: A later version (-09) exists of draft-housley-aaa-key-mgmt-06 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HOKEY Working Group T. Clancy, Editor 3 Internet-Draft LTS 4 Intended status: Informational January 16, 2007 5 Expires: July 20, 2007 7 Handover Key Management and Re-authentication Problem Statement 8 draft-ietf-hokey-reauth-ps-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on July 20, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2007). 39 Abstract 41 This document describes the Handover Keying (HOKEY) problem 42 statement. The current EAP keying framework is not designed to 43 support re-authentication and handovers. This often cause 44 unacceptable latency in various mobile wireless environments. HOKEY 45 plans to address these HOKEY plans to address these problems by 46 implementing a generic mechanism to reuse derived EAP keying material 47 for hand-off. 49 Table of Contents 51 1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 55 5. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 6. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 6 57 6.1. Key Context and Domino Effect . . . . . . . . . . . . . . 6 58 6.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 7 59 6.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 7 60 6.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 7 61 6.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 8 62 6.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 8 63 7. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 8 64 7.1. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 9 65 7.2. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 9 66 7.3. Inter-Technology Hand-Off . . . . . . . . . . . . . . . . 10 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 71 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 Intellectual Property and Copyright Statements . . . . . . . . . . 12 75 1. Authors 77 The following authors contributed to the HOKEY problem statement 78 draft: 80 o Julien Bournelle, France Telecom R&D, 81 julien.bournelle@orange-ftgroup.com 82 o Lakshminath Dondeti, QUALCOMM, ldondeti@qualcomm.com 83 o Rafael Marin Lopez, Universidad de Murcia, rafa@dif.um.es 84 o Madjid Nakhjiri, Huawei, mnakhjiri@huawei.com 85 o Vidya Narayanan, QUALCOMM, vidyan@qualcomm.com 86 o Mohan Parthasarathy, Nokia, mohan.parthasarathy@nokia.com 87 o Hannes Tschofenig, Siemens, Hannes.Tschofenig@siemens.com 89 2. Introduction 91 The extensible authentication protocol (EAP), specified in RFC3748 92 [RFC3748] is a generic framework supporting multiple authentication 93 methods. The primary purpose of EAP is network access control. It 94 also supports exporting session keys derived during the 95 authentication. The EAP keying hierarchy defines two keys that are 96 derived at the top level, the master session key (MSK) and the 97 extended MSK (EMSK). 99 In many common deployment scenario, an EAP peer and EAP server 100 authenticate each other through a third party known as the pass- 101 through authenticator (hereafter referred to as simply 102 "authenticator"). The authenticator is responsible for translating 103 EAP packets from the layer 2 (L2) or layer 3 (L3) network access 104 technology to the AAA protocol. 106 According to [RFC3748], after successful authentication, the server 107 transports the MSK to the authenticator. The underlying L2 or L3 108 protocol uses the MSK to derive additional keys, including the 109 transient session keys (TSK) used per-packet access encryption and 110 enforcement. Figure Figure 1 depicts this process. 112 +--------+ +---------------+ +----------+ 113 | EAP |<----->| Passthrough |<--->| EAP | 114 | Client | L2/L3 | Authenticator | AAA | Server | 115 +--------+ +---------------+ +----------+ 117 <------------- EAP Authentication ----------> 119 <---- MSK Transport ---- 121 <-- TSK Generation --> 123 Figure 1: Logical diagram of EAP authentication and key derivation 124 using passthrough authenticator 126 Note that while the authenticator is one logical device, there can be 127 many physical devices involved. For example, in the CAPWAP model 128 [RFC3990] WTPs communicate using L2 protocols with the EAP client and 129 ACs communicate using AAA to the EAP server, while using CAPWAP 130 protocols to communicate with each other. Depending on the 131 configuration, authenticator features can be split in a variety of 132 ways between physical devices, however from the EAP perspective there 133 is only one logical authenticator. 135 The current models of EAP authentication and keying are unfortunately 136 not efficient in case of mobile and wireless networks. When a peer 137 arrives at the new authenticator, or is expected to re-affirm its 138 access through the current authenticator, the security restraints 139 will require the peer to run an EAP method irrespective of whether it 140 has been authenticated to the network recently and has unexpired 141 keying material. A full EAP method execution involves several round 142 trips between the EAP peer and the server. 144 There have been attempts to solve the problem of efficient re- 145 authentication in various ways. However, those solutions are either 146 EAP-method specific, EAP lower-layer specific, or are otherwise 147 limited in scope. Furthermore, these solutions do not deal with 148 scenarios involving handovers to new authenticators, or do not 149 conform to the AAA keying requirements specified in 150 [I-D.housley-aaa-key-mgmt]. 152 This document provides a detailed description of EAP efficient re- 153 authentication protocol requirements. 155 3. Terminology 157 In this document, several words are used to signify the requirements 158 of the specification. These words are often capitalized. The key 159 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 160 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 161 are to be interpreted as described in [RFC2119]. 163 This document follows the terminology that has been defined in 164 RFC3748 [RFC3748] and the EAP Keying Framework [I-D.ietf-eap-keying]. 166 4. Problem Statement 168 When a peer needs to re-affirm access to an authenticator or moves 169 from one authenticator and reattaches to another authenticator, the 170 current EAP keying model requires the peer to engage in a full EAP 171 exchange with the authentication server in its home domain [RFC3748]. 173 An EAP conversation with a full EAP method run takes several round 174 trips and significant time to complete, causing delays in re- 175 authentication and hand-off times. Some methods [RFC4187] specify 176 the use of keys and state from the initial authentication to finish 177 subsequent authentications in fewer round trips. However, even in 178 those cases, several round trips to the EAP server are still 179 involved. Furthermore, many commonly-used EAP methods do not offer 180 such a fast re-authentication feature. In summary, it is undesirable 181 to have to run a full EAP method each time a peer associates with a 182 new authenticator or needs to extend its current association with the 183 same authenticator. Furthermore, it is desirable to specify a 184 method-independent, efficient, re-authentication protocol. Keying 185 material from the full authentication can be used to enable efficient 186 re-authentication. 188 Another problem with respect to authentication is when the EAP server 189 is several hops away from the peer, causing too much delay in 190 executing the re-authentication. It is desirable to allow a locally 191 reachable server with EAP efficient re-authentication capability with 192 which the peer can execute such re-authentication without having to 193 involve the original EAP server all the time. An EAP re- 194 authentication solution defined MUST NOT prevent its extension to a 195 fast re-authentication protocol that operates between EAP servers, 196 and the defined keying hierarchy MUST be designed such that this 197 could be supported. 199 These problems are the primary issue to be resolved. In solving 200 them, there are a number of constraints to conform to and those 201 result in some additional work to be done in the area of EAP keying. 203 5. Design Goals 205 The following are the goals and constraints in designing the EAP re- 206 authentication and key management protocol: 208 Lower latency operation: The protocol MUST be responsive to handover 209 and re-authentication latency performance objectives within a 210 mobile access network. A solution that reduces latency as 211 compared to a full EAP authentication will be most favorable. 212 EAP lower-layer independence: Any keying hierarchy and protocol 213 defined MUST be lower layer independent in order to provide the 214 capability over heterogeneous technologies. The defined protocols 215 MAY require some additional support from the lower layers that use 216 it. Any keying hierarchy and protocol defined MUST accommodate 217 inter-technology heterogeneous handover. 218 EAP method independence: Changes to existing EAP methods MUST NOT be 219 required as a result of the re-authentication protocol. There 220 MUST be no requirements imposed on future EAP methods. Note that 221 the only EAP methods for which independence is required are those 222 that conform to the specifications of [I-D.ietf-eap-keying] and 223 [RFC4017]. 224 AAA protocol compatibility and keying: Any modifications to EAP and 225 EAP keying MUST be compatible with RADIUS and Diameter. 226 Extensions to both RADIUS and Diameter to support these EAP 227 modifications are acceptable. The designs and protocols must 228 satisfy the AAA key management requirements specified in 229 [I-D.housley-aaa-key-mgmt]. 230 Compatability: Compatibility and especially co-existence with 231 current EAP implementations and deployment SHOULD be provided. 232 Compatibility with other fast transition mechanisms SHOULD also be 233 provided. The keying hierarchy or protocol extensions MUST NOT 234 preclude the use of CAPWAP or IEEE 802.11r. 236 6. Security Goals 238 The section draws from the guidance provided in 239 [I-D.housley-aaa-key-mgmt] to further define the security goals to be 240 achieved by a complete re-authentication keying solution. 242 6.1. Key Context and Domino Effect 244 Any key MUST have a well-defined scope and MUST be used in a specific 245 context and for the intended use. This specifically means the 246 lifetime and scope of each key MUST be defined clearly so that all 247 entities that are authorized to have access to the key have the same 248 context during the validity period. In a hierarchical key structure, 249 the lifetime of lower level keys MUST NOT exceed the lifetime of 250 higher level keys. This requirement MAY imply that the context and 251 the scope parameters have to be exchanged. Furthermore, the 252 semantics of these parameters MUST be defined to provide proper 253 channel binding specifications. The definition of exact parameter 254 syntax definition is part of the design of the transport protocol 255 used for the parameter exchange and that may be outside scope of this 256 protocol. 258 If a key hierarchy is deployed, compromising lower level keys MUST 259 NOT result in a compromise of higher level keys which they were used 260 to derive the lower level keys. The compromise of keys at each level 261 MUST NOT result in compromise of other keys at the same level. The 262 same principle applies to entities that hold and manage a particular 263 key defined in the key hierarchy. Compromising keys on one 264 authenticator MUST NOT reveal the keys of another authenticator. 265 Note that the compromise of higher-level keys has security 266 implications on lower levels. 268 Guidance on parameters required, caching, storage and deletion 269 procedures to ensure adequate security and authorization provisioning 270 for keying procedures MUST be defined in a solution document. 272 All the keying material MUST be uniquely named so that it can be 273 managed effectively. 275 6.2. Key Freshness 277 As [I-D.housley-aaa-key-mgmt] defines, a fresh key is one that is 278 generated for the intended use. This would mean the key hierarchy 279 MUST provide for creation of multiple cryptographically separate 280 child keys from a root key at higher level. Furthermore, the keying 281 solution needs to provide mechanisms for authorized refreshing each 282 of the keys within the key hierarchy. 284 6.3. Authentication 286 Each party in the handover keying architecture MUST be authenticated 287 to any other party with whom it communicates, and securely provide 288 its identity to any other entity that may require the identity for 289 defining the key scope. The identity provided MUST be meaningful 290 according to the protocol over which the two parties communicate. 292 6.4. Authorization 294 The EAP Key management document [I-D.ietf-eap-keying] discusses 295 several vulnerabilities that are common to handover mechanisms. One 296 important issue arises from the way the authorization decisions might 297 be handled at the AAA server during network access authentication. 299 For example, if AAA proxies are involved, they may also influence in 300 the authorization decision. Furthermore, the reasons for making a 301 particular authorization decision are not communicated to the 302 authenticator. In fact, the authenticator only knows the final 303 authorization result. The proposed solution MUST make efforts to 304 document and mitigate authorization attacks. 306 6.5. Channel Binding 308 Channel Binding procedures are needed to avoid a compromised 309 intermediate authenticator providing unverified and conflicting 310 service information to each of the peer and the EAP server. In the 311 architecture introduced in this document, there are multiple 312 intermediate entities between the peer and the back-end EAP server. 313 Various keys need to be established and scoped between these parties 314 and some of these keys may be parents to other keys. Hence the 315 channel binding for this architecture will need to consider layering 316 intermediate entities at each level to make sure that an entity with 317 higher level of trust can examine the truthfulness of the claims made 318 by intermediate parties. 320 6.6. Transport Aspects 322 Depending on the physical architecture and the functionality of the 323 elements involved, there may be a need for multiple protocols to 324 perform the key transport between entities involved in the handover 325 keying architecture. Thus, a set of requirements for each of these 326 protocols, and the parameters they will carry, MUST be developed. 327 Following the requirement specifications, recommendations will be 328 provided as to whether new protocols or extensions to existing 329 protocols are needed. 331 As mentioned, the use of existing AAA protocols for carrying EAP 332 messages and keying material between the AAA server and AAA clients 333 that have a role within the architecture considered for the keying 334 problem will be carefully examined. Definition of specific 335 parameters, required for keying procedures and to be transferred over 336 any of the links in the architecture, are part of the scope. The 337 relation of the identities used by the transport protocol and the 338 identities used for keying also needs to be explored. 340 7. Use Cases and Related Work 342 In order to further clarify the items listed in scope of the proposed 343 work, this section provides some background on related work and the 344 use cases envisioned for the proposed work. 346 7.1. IEEE 802.11r Applicability 348 One of the EAP lower layers, IEEE 802.11, provides a mechanism to 349 avoid the problem of repeated full EAP exchanges in a limited 350 setting, by introducing a two-level key hierarchy. The EAP 351 authenticator is collocated with what is known as an R0 Key Holder 352 (R0-KH), which receives the MSK from the EAP server. A pairwise 353 master key (PMK-R0) is derived from the last 32 octets of the MSK. 354 Subsequently, the R0-KH derives an PMK-R1 to be handed out to the 355 attachment point of the peer. When the peer moves from one R1-KH to 356 another, a new PMK-R1 is generated by the R0-KH and handed out to the 357 new R1-KH. The transport protocol used between the R0-KH and the 358 R1-KH is not specified at the moment. 360 In some cases, a mobile may seldom move beyond the domain of the 361 R0-KH and this model works well. A full EAP authentication will 362 generally be repeated when the PMK-R0 expires. However, in general 363 cases mobiles may roam beyond the domain of R0-KHs (or EAP 364 authenticators), and the latency of full EAP authentication remains 365 an issue. 367 Another consideration is that there needs to be a key transfer 368 protocol between the R0-KH and the R1-KH; in other words, there is 369 either a star configuration of security associations between the key 370 holder and a centralized entity that serves as the R0-KH, or if the 371 first authenticator is the default R0-KH, there will be a full-mesh 372 of security associations between all authenticators. This is 373 undesirable. 375 Furthermore, in the 802.11r architecture, the R0-KH may actually be 376 located close to the edge, thereby creating a vulnerability: If the 377 R0-KH is compromised, all PMK-R1s derived from the corresponding PMK- 378 R0s will also be compromised. 380 The proposed work on EAP efficient re-authentication protocol aims at 381 addressing the problem in a lower layer agnostic manner that also can 382 operate without some of the restrictions or shortcomings of 802.11r 383 mentioned above. 385 7.2. CAPWAP Applicability 387 The IETF CAPWAP WG is developing a protocol between what is termed an 388 Access Controller (AC) and Wireless Termination Points (WTP). The AC 389 and WTP can be mapped to a WLAN switch and Access Point respectively. 390 The CAPWAP model supports both split and integrated MAC 391 architectures, with the authenticator always being implemented at the 392 AC. 394 The proposed work on EAP efficient re-authentication protocol 395 addresses an inter-authenticator hand-off problem from an EAP 396 perspective, which applies during hand-off between ACs. Inter- 397 controller hand-offs is a topic yet to be addressed in great detail 398 and the re-authentication work can potentially address it in an 399 effective manner. 401 7.3. Inter-Technology Hand-Off 403 EAP is used for access authentication by several technologies and is 404 under consideration for use over several other technologies going 405 forward. Given that, it should be feasible to support smoother hand- 406 offs across technologies. That is one of the big advantages of using 407 a common authentication protocol. Authentication procedures 408 typically add substantial hand-off delays. 410 An EAP peer that has multiple radio technologies (802.11 and GSM, for 411 instance) must perform the full EAP exchange on each interface upon 412 every horizontal or vertical hand-off. With a method independent EAP 413 efficient re-authentication, it is feasible to support faster hand- 414 offs even in the vertical hand-off cases, when the peer may be 415 roaming from one technology to another. 417 8. Security Considerations 419 This document details the HOKEY problem statement. Since HOKEY is an 420 authentication protocol, there are a myriad of security-related 421 issues surrounding its development and deployment. 423 In this document, we have detailed a variety of security properties 424 inferred from [I-D.housley-aaa-key-mgmt] to which HOKEY must conform, 425 including the management of key context, scope, freshness, and 426 transport; resistance to attacks based on the domino effect; and 427 authentication and authorization. See section Section 6 for further 428 details. 430 9. IANA Considerations 432 This document does not introduce any new IANA considerations. 434 10. References 435 10.1. Normative References 437 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 438 Requirement Levels", BCP 14, RFC 2119, March 1997. 440 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 441 Levkowetz, "Extensible Authentication Protocol (EAP)", 442 RFC 3748, June 2004. 444 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 445 Authentication Protocol (EAP) Method Requirements for 446 Wireless LANs", RFC 4017, March 2005. 448 [I-D.ietf-eap-keying] 449 Aboba, B., "Extensible Authentication Protocol (EAP) Key 450 Management Framework", draft-ietf-eap-keying-16 (work in 451 progress), January 2007. 453 [I-D.housley-aaa-key-mgmt] 454 Housley, R. and B. Aboba, "Guidance for AAA Key 455 Management", draft-housley-aaa-key-mgmt-06 (work in 456 progress), November 2006. 458 10.2. Informative References 460 [RFC3990] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and 461 Provisioning for Wireless Access Points (CAPWAP) Problem 462 Statement", RFC 3990, February 2005. 464 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 465 Protocol Method for 3rd Generation Authentication and Key 466 Agreement (EAP-AKA)", RFC 4187, January 2006. 468 Author's Address 470 T. Charles Clancy, Editor 471 DoD Laboratory for Telecommunications Sciences 472 8080 Greenmead Drive 473 College Park, MD 20740 474 USA 476 Email: clancy@LTSnet.net 478 Full Copyright Statement 480 Copyright (C) The Internet Society (2007). 482 This document is subject to the rights, licenses and restrictions 483 contained in BCP 78, and except as set forth therein, the authors 484 retain all their rights. 486 This document and the information contained herein are provided on an 487 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 488 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 489 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 490 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 491 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 492 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 494 Intellectual Property 496 The IETF takes no position regarding the validity or scope of any 497 Intellectual Property Rights or other rights that might be claimed to 498 pertain to the implementation or use of the technology described in 499 this document or the extent to which any license under such rights 500 might or might not be available; nor does it represent that it has 501 made any independent effort to identify any such rights. Information 502 on the procedures with respect to rights in RFC documents can be 503 found in BCP 78 and BCP 79. 505 Copies of IPR disclosures made to the IETF Secretariat and any 506 assurances of licenses to be made available, or the result of an 507 attempt made to obtain a general license or permission for the use of 508 such proprietary rights by implementers or users of this 509 specification can be obtained from the IETF on-line IPR repository at 510 http://www.ietf.org/ipr. 512 The IETF invites any interested party to bring to its attention any 513 copyrights, patents or patent applications, or other proprietary 514 rights that may cover technology that may be required to implement 515 this standard. Please address the information to the IETF at 516 ietf-ipr@ietf.org. 518 Acknowledgment 520 Funding for the RFC Editor function is provided by the IETF 521 Administrative Support Activity (IASA).