idnits 2.17.1 draft-arkko-radext-multi-service-decisions-02.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 511. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 488. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 495. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 501. ** 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 'Intended status' indicated for this document; assuming Proposed Standard 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 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 (October 24, 2005) is 6759 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) -- Looks like a reference, but probably isn't: 'RFC3576' on line 187 -- Looks like a reference, but probably isn't: 'RFC3336' on line 240 -- Looks like a reference, but probably isn't: 'RFC2516' on line 244 -- Looks like a reference, but probably isn't: 'RFC2411' on line 246 -- Looks like a reference, but probably isn't: 'RFC3580' on line 267 ** Downref: Normative reference to an Informational RFC: RFC 2868 (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 3580 (ref. '4') ** Obsolete normative reference: RFC 3588 (ref. '5') (Obsoleted by RFC 6733) == Outdated reference: A later version (-18) exists of draft-ietf-pana-pana-05 -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. '9') (Obsoleted by RFC 4306) == Outdated reference: A later version (-04) exists of draft-arkko-eap-service-identity-auth-00 -- No information found for draft-lebovitz-ipsec-scalable-ikev2cp - is the name correct? == Outdated reference: A later version (-04) exists of draft-zorn-radius-port-type-00 Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RADEXT J. Arkko 3 Internet-Draft Ericsson 4 Expires: April 27, 2006 P. Eronen 5 Nokia 6 J. Korhonen 7 Teliasonera 8 October 24, 2005 10 Policy Decisions for Users with Access to Multiple Services 11 draft-arkko-radext-multi-service-decisions-02 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 27, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This draft relates to the use of Authentication, Authorization, and 45 Accounting (AAA) where the same user credentials can be used on many 46 different types of devices, ranging from wireless access points to 47 Virtual Private Network (VPN) gateways. This draft discusses how to 48 use existing AAA and authentication protocols and extensions to 49 determine what service was provided, agree about this among all the 50 participating parties, and use this information as a basis for policy 51 decisions. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Requirements language . . . . . . . . . . . . . . . . . . . . 4 57 3. Policy Decisions . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Deployment Considerations in a Roaming Setting . . . . . . . . 6 59 5. Ensuring Parties Have the Same Information . . . . . . . . . . 7 60 6. Determining the Type of Service . . . . . . . . . . . . . . . 8 61 6.1. Service-Type Attribute . . . . . . . . . . . . . . . 8 62 6.2. NAS-Port-Type Attribute . . . . . . . . . . . . . . 8 63 6.3. Tunnel-Type and Tunnel-Medium-Type Attributes . . . 10 64 6.4. Discussion . . . . . . . . . . . . . . . . . . . . . 11 65 7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 12 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 9.1. Normative References . . . . . . . . . . . . . . . . 14 69 9.2. Informative References . . . . . . . . . . . . . . . 14 70 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 16 71 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 17 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 73 Intellectual Property and Copyright Statements . . . . . . . . . . 19 75 1. Introduction 77 This draft relates to the use of Authentication, Authorization, and 78 Accounting (AAA) where the same user credentials can be used on many 79 different types of devices, ranging from wireless access points to 80 virtual network gateways. For instance, a user may have credentials 81 that can be used in the Extensible Authentication Protocol (EAP) [6]. 82 Such credentials could be used to access a 802.11 Wireless LAN, 83 802.16 networks, PANA-based DSL [8], or to gain VPN access via a 84 gateway that supports IKEv2 [7]. 86 Among other things, this draft discusses how AAA servers can 87 determine what service was provided. This is important in some 88 situations where, for policy reasons, the type of the service needs 89 to be known. Such policy may be based on, for instance, commercial 90 or security considerations. 92 For example, the AAA server may wish to deny 802.1X wireless LAN 93 access from a service for a specific subscriber, but allow the same 94 subscriber to use IKEv2-based VPNs. The attributes discussed in this 95 document will provide this information to the AAA server. The AAA 96 server uses this information at the moment of the authorization 97 decision, and once this decision is taken, the rest of the exchange 98 is not affected. 100 Similarly, it can be useful to ensure that the client, NAS, and AAA 101 server all know what service was provided, or even ensure that the 102 client knows the NAS has provided a service that the AAA server has 103 authorized. 105 Earlier work in this space includes [11], [12], and [10] to which 106 this work is in debt. 108 2. Requirements language 110 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 111 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 112 described in [1]. 114 3. Policy Decisions 116 Security-related policies can be required when potential service 117 types have different perceived security levels. For instance, 118 network access using a particular link layer type might be considered 119 insecure, while other link layer types or VPN access would be secure. 121 A more subtle need knowledge about the provided service relates to 122 possibility of compromised nodes. In a large distributed network it 123 is often desirable that the compromise of a single node does not 124 affect other nodes. For instance, it would be desirable that a 125 compromised 802.11 access point can not be turned into a company VPN 126 gateway. 128 An example of a business-related policy is a subscription that 129 applies only to a particular type of an access. 131 4. Deployment Considerations in a Roaming Setting 133 AAA servers may have full knowledge of what services specific NASes 134 offer. For instance, a AAA server may know that a NAS with one 135 address and a shared secret is a Wireless LAN access point, and 136 another NAS with a different address and secret is a VPN gateway. 137 This information can be configured in the AAA server and used for 138 making policy decisions. 140 Generally, such configuration is, however, infeasible in a roaming 141 setting, due to the large number of potential NASes and the different 142 organizations involved. (There can be some situations where this is 143 still possible even with roaming. For instance, if the roaming 144 network provides only Wireless LAN access, and the operator's own 145 device provides VPN access then it is always possible to distinguish 146 the two.) 148 Due to these problems, we typically rely on information transferred 149 in the AAA protocols to make policy decisions. For instance, many 150 service parameters (interface speed, type) are carried in the 151 protocols and an informed decision is possible. Nevertheless, as 152 discussed in [10], such information is vulnerable to lying NASes. 154 5. Ensuring Parties Have the Same Information 156 Where EAP is used, [10] can provide a channel that ensures the NAS 157 has provided the same information to the client and the AAA server. 159 This solution requires support from EAP methods. As a result, it may 160 not always apply, if an EAP method that does not support it is used. 161 While the specification supports most popular EAP methods, no 162 deployment of this solution is known to date. 164 6. Determining the Type of Service 166 6.1. Service-Type Attribute 168 This attribute represents the highest level of service provided by a 169 NAS. The current allocation is shown below: 171 1 Login 172 2 Framed 173 3 Callback Login 174 4 Callback Framed 175 5 Outbound 176 6 Administrative 177 7 NAS Prompt 178 8 Authenticate Only 179 9 Callback NAS Prompt 180 10 Call Check 181 11 Callback Administrative 182 12 Voice 183 13 Fax 184 14 Modem Relay 185 15 IAPP-Register [IEEE 802.11f] 186 16 IAPP-AP-Check [IEEE 802.11f] 187 17 Authorize Only [RFC3576] 189 Most current network access falls under the "2 - Framed" value. New 190 values could be allocated, but generally it is more appropriate to 191 allocate new NAS-Port-Type values than a complete new Service-Type 192 value. It is also expected that implementations may deal with 193 Service-Type attribute in a special way, so changes to this attribute 194 would lead to code impacts. 196 6.2. NAS-Port-Type Attribute 198 The current assignment of NAS-Port-Type values is shown below: 200 0 Async 201 1 Sync 202 2 ISDN Sync 203 3 ISDN Async V.120 204 4 ISDN Async V.110 205 5 Virtual 206 6 PIAFS 207 7 HDLC Clear Channel 208 8 X.25 209 9 X.75 210 10 G.3 Fax 211 11 SDSL - Symmetric DSL 212 12 ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase 213 Modulation 214 13 ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone 215 14 IDSL - ISDN Digital Subscriber Line 216 15 Ethernet 217 16 xDSL - Digital Subscriber Line of unknown type 218 17 Cable 219 18 Wireless - Other 220 19 Wireless - IEEE 802.11 221 20 Token-Ring 222 21 FDDI 223 22 Wireless - CDMA2000 224 23 Wireless - UMTS 225 24 Wireless - 1X-EV 226 25 IAPP 227 26 FTTP - Fiber to the Premises 229 This attribute can in general distinguish a number of different 230 physical port types, for instance between 802.11 Wireless LANs (value 231 19) and Token Ring (20) [4]. New port types can be allocated easily 232 as new access technologies come into use. 234 Distinguishing different virtual ports is not possible, however. 235 This is because just one value (5 - Virtual) has been allocated for 236 them. 238 Some additional values have also been suggested in [13]: 240 30 PPPoA (PPP over ATM [RFC3336]) 241 31 PPPoEoA (PPP over Ethernet [RFC2516] over ATM) 242 32 PPPoEoE (PPP over Ethernet [RFC2516] over Ethernet 243 33 PPPoEoVLAN (PPP over Ethernet [RFC2516] over VLAN) 244 34 PPPoEoQinQ (PPP over Ethernet [RFC2516] over IEEE 245 802.1QinQ) 246 38 IPSEC [RFC2411] 248 6.3. Tunnel-Type and Tunnel-Medium-Type Attributes 250 Tunnel attributes defined in RFC 2868 [3] make it possible to 251 distinguish between different types of tunnel types and media over 252 which the tunnel is run. The current tunnel types are: 254 1 Point-to-Point Tunneling Protocol (PPTP) 255 2 Layer Two Forwarding (L2F) 256 3 Layer Two Tunneling Protocol (L2TP) 257 4 Ascend Tunnel Management Protocol (ATMP) 258 5 Virtual Tunneling Protocol (VTP) 259 6 IP Authentication Header in the Tunnel-mode (AH) 260 7 IP-in-IP Encapsulation (IP-IP) 261 8 Minimal IP-in-IP Encapsulation (MIN-IP-IP) 262 9 IP Encapsulating Security Payload in the Tunnel-mode 263 (ESP) 264 10 Generic Route Encapsulation (GRE) 265 11 Bay Dial Virtual Services (DVS) 266 12 IP-in-IP Tunneling 267 13 Virtual LANs (VLAN) [RFC3580] 269 And the medium types are: 271 1 IPv4 (IP version 4) 272 2 IPv6 (IP version 6) 273 3 NSAP 274 4 HDLC (8-bit multidrop) 275 5 BBN 1822 276 6 802 (includes all 802 media plus Ethernet "canonical 277 format") 278 7 E.163 (POTS) 279 8 E.164 (SMDS, Frame Relay, ATM) 280 9 F.69 (Telex) 281 10 X.121 (X.25, Frame Relay) 282 11 IPX 283 12 Appletalk 284 13 Decnet IV 285 14 Banyan Vines 286 15 E.164 with NSAP format subaddress 288 Together with the NAS-Port-Type attribute, these attributes make it 289 possible to distinguish, for instance, between IPsec- and L2TP-based 290 tunnels. Furthermore, it is possible to separate the medium over 291 which the tunnel runs from the tunnel itself. These attributes are 292 today primarily used to control mandatory tunneling from a NAS (i.e., 293 from NAS to somewhere else, not between NAS and the client). 295 Note that the role of the tunnel (incoming or outgoing) is not 296 explicitly communicated. If this information is needed, it can be 297 recovered by comparing the NAS-IP-Address attribute to the Tunnel- 298 Client-Endpoint and Tunnel-Server-Endpoint addresses. This 299 comparison assumes, however, that the addressing domains are the 300 same, which may not always be the case. For instance, a typical VPN 301 gateway would provide a Tunnel-Server-Endpoint of its public IP 302 address and a NAS-IP-Address of its internal network interface. 304 Similarly, if the NAS needs both types of tunnels simultaneously, the 305 attributes can not distinguish between them. For instance, if a NAS 306 has terminated an IPsec tunnel, the AAA server can not request it to 307 create another mandatory tunnel to another location. This is because 308 the NAS would interpret such request (in Access-Accept) as a 309 rejection of its incoming IPsec tunnel. This prevents, for instance, 310 the use of a AAA server to control which VLAN an incoming VPN users 311 should be directed to. 313 Another limitation is that RFC 2868 attributes do not explicitly 314 distinguish between different key management mechanisms for tunnels. 315 We do not know, however, to how large extent other than the default 316 key management mechanisms are being employed. For instance, it seems 317 fairly safe to assume that either IKEv1 [9] or IKEv2 [7] is used to 318 key IPsec-based VPNs. Other alternatives do exist, however. 320 6.4. Discussion 322 As long as a suitable NAS-Port-Type value exists, it can be reliably 323 be used to determine the type of the service. What remains is 324 distinguishing different virtual services from each other. Both NAS- 325 Port-Type value additions (see [13] and tunnel attribute approaches 326 have been suggested. 328 One open issue is whether the proposed NAS-Port-Type value "IPsec" 329 should be used instead of "Virtual" when using an IPsec-based virtual 330 service. Another question is under what assumptions the tunnel 331 attribute support is sufficient when both incoming and outgoing 332 tunnels are considered. 334 7. Recommendations 336 It is suggested that new physical interface types lead to the 337 allocation of new NAS-Port-Type values. 339 New higher-layer network access mechanisms, such as PANA, can acquire 340 either a new NAS-Port-Type value or new Tunnel-Type value. In the 341 former case, however, existing DSL or Ethernet port type allocations 342 are not used. This would also create an additional need to have 343 combinations represented in the port types, e.g., PANA over Ethernet 344 and PANA over DSL. As a result, it is recommended that a new Tunnel- 345 Type value, or another similar attribute be used for that purpose. 346 (Intuitively, PANA is not a "tunnel". The question of whether PANA 347 and other "layer 2.5" solutions should be categorized as tunnels 348 deserves some discussion.) 350 Existing RFC 2868 attributes are sufficient for some situations, but 351 not all. We have not determined whether the remaining cases are 352 important enough to need specific support. If such support would be 353 needed, one option would be to provide additional distinguishing 354 tunnel attributes, such as tunnel role. Another approach would be to 355 provide an independent attribute model. 357 A common scenario is where both physical (e.g., 802.11) access and a 358 VPN service is being deployed using the same credential. One 359 approach for distinguishing these two in an AAA transaction is to use 360 the values NAS-Port-Type = 5 (Virtual ) or NAS-Port-Type = 38 (IPSEC) 361 to represent a VPN service, and all other values to represent a 362 physical access. Value 38 is currently not defined in any RFC or 363 even active draft, and hence only value 5 would be a practical 364 choice. However, this approach is not guaranteed to operate 365 correctly when types of services are being developed. 367 It has been suggested that this approach could in addition use of 368 tunnel attributes, but this is not recommended due the overloading of 369 their semantics for both incoming and outgoing tunnels. 371 8. Security Considerations 373 Security is one of the reasons for attempting to carry information 374 about the type of provided virtual service to the AAA servers, as 375 discussed in Section 1. 377 This draft does not add any new protocol mechanisms, and as such it 378 does not add new security issues beyond those that already exist for 379 general AAA usage. See [2] and [5] for further discussion. 381 Note that while providing information from a NAS to a AAA server 382 helps enforce policies, it is unable to deal with rogue NASes, as 383 there is no way forgeries by legitimate (but turned rogue) NASes can 384 be detected. Where EAP is used for authentication, the end-to-end 385 secure channel between the EAP peer and the EAP server can help 386 ensure that all parties at least agree on what the provided service 387 was [10]. That is, the NAS would be forced to tell the same 388 information both to the peer and the AAA server. 390 9. References 392 9.1. Normative References 394 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 395 Levels", BCP 14, RFC 2119, March 1997. 397 [2] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 398 Authentication Dial In User Service (RADIUS)", RFC 2865, 399 June 2000. 401 [3] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and 402 I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", 403 RFC 2868, June 2000. 405 [4] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 406 802.1X Remote Authentication Dial In User Service (RADIUS) Usage 407 Guidelines", RFC 3580, September 2003. 409 [5] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 410 "Diameter Base Protocol", RFC 3588, September 2003. 412 [6] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 413 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, 414 June 2004. 416 [7] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 417 draft-ietf-ipsec-ikev2-17 (work in progress), October 2004. 419 [8] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. Yegin, 420 "Protocol for Carrying Authentication for Network Access 421 (PANA)", draft-ietf-pana-pana-05 (work in progress), July 2004. 423 9.2. Informative References 425 [9] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 426 RFC 2409, November 1998. 428 [10] Arkko, J. and P. Eronen, "Authenticated Service Identities for 429 the Extensible Authentication Protocol (EAP)", 430 draft-arkko-eap-service-identity-auth-00 (work in progress), 431 April 2004. 433 [11] Mariblanca, D., "EAP lower layer attributes for AAA protocols", 434 draft-mariblanca-aaa-eap-lla-01 (work in progress), June 2004. 436 [12] Lebovitz, G., "EAP lower layer attributes for AAA protocols", 437 draft-lebovitz-ipsec-scalable-ikev2cp-00.txt (unpublished) 438 (work in progress), March 2003. 440 [13] Zorn, G., "Additional Values for the NAS-Port-Type Attribute", 441 draft-zorn-radius-port-type-00 (work in progress), 442 February 2005. 444 Appendix A. Contributors 446 Glen Zorn and David Mariblanca were members of our team, and 447 contributed greatly to the discussions. 449 Appendix B. Acknowledgements 451 We would like to thank Jouni Korhonen, Dave Nelson, and Bernard Aboba 452 for interesting discussions in this problem space. 454 Authors' Addresses 456 Jari Arkko 457 Ericsson 458 Jorvas FI-02420 459 Finland 461 Email: jari.arkko@ericsson.com 463 Pasi Eronen 464 Nokia Research Center 465 P.O. Box 407 466 FI-00045 Nokia Group 467 Finland 469 Email: pasi.eronen@nokia.com 471 Jouni Korhonen 472 Teliasonera Corporation 473 P.O. Box 970 474 FI-00051 Sonera 475 Finland 477 Email: jouni.korhonen@teliasonera.com 479 Intellectual Property Statement 481 The IETF takes no position regarding the validity or scope of any 482 Intellectual Property Rights or other rights that might be claimed to 483 pertain to the implementation or use of the technology described in 484 this document or the extent to which any license under such rights 485 might or might not be available; nor does it represent that it has 486 made any independent effort to identify any such rights. Information 487 on the procedures with respect to rights in RFC documents can be 488 found in BCP 78 and BCP 79. 490 Copies of IPR disclosures made to the IETF Secretariat and any 491 assurances of licenses to be made available, or the result of an 492 attempt made to obtain a general license or permission for the use of 493 such proprietary rights by implementers or users of this 494 specification can be obtained from the IETF on-line IPR repository at 495 http://www.ietf.org/ipr. 497 The IETF invites any interested party to bring to its attention any 498 copyrights, patents or patent applications, or other proprietary 499 rights that may cover technology that may be required to implement 500 this standard. Please address the information to the IETF at 501 ietf-ipr@ietf.org. 503 Disclaimer of Validity 505 This document and the information contained herein are provided on an 506 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 507 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 508 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 509 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 510 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 511 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 513 Copyright Statement 515 Copyright (C) The Internet Society (2005). This document is subject 516 to the rights, licenses and restrictions contained in BCP 78, and 517 except as set forth therein, the authors retain all their rights. 519 Acknowledgment 521 Funding for the RFC Editor function is currently provided by the 522 Internet Society.