idnits 2.17.1 draft-friedman-ike-short-term-certs-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, updated by RFC 4748 on line 496. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 507. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 514. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 520. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (June 20, 2007) is 6156 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-07) exists of draft-ietf-ipsra-pic-06 -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 3280 (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 4330 (Obsoleted by RFC 5905) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Friedman 3 Internet-Draft Technion IIT 4 Intended status: Experimental Y. Sheffer 5 Expires: December 22, 2007 Check Point 6 A. Shaqed 7 Correlix, Inc. 8 June 20, 2007 10 Short-Term Certificates 11 draft-friedman-ike-short-term-certs-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 December 22, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document describes an extension to IKEv2 that allows an endpoint 45 which has authenticated to a gateway to request a short-term 46 credential, possession of which proves the authentication. This 47 allows it to prove to a security gateway that it was already 48 authenticated by another trusted security gateway, thereby allowing 49 the authentication of the endpoint without user intervention. This 50 credential is a certificate issued by the authenticating gateway for 51 a short period of time, which can be used to authenticate the user 52 with IKE signature based authentication. 54 Requirements Language 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC 2119 [RFC2119]. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Short-Term Certificate Usage . . . . . . . . . . . . . . . . . 4 65 4. Short-Term Certificates Issue Exchange . . . . . . . . . . . . 5 66 5. Using Short-Term Certificates . . . . . . . . . . . . . . . . 8 67 6. Expiration of Short-Term Certificates . . . . . . . . . . . . 8 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 9. Operational Considerations . . . . . . . . . . . . . . . . . . 9 71 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 74 11.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 76 Intellectual Property and Copyright Statements . . . . . . . . . . 12 78 1. Introduction 80 Many organizations manage one or more security gateways that provide 81 IPsec [RFC4301] services, to allow secured connectivity between 82 roaming endpoints and the organizational site, as well as between the 83 organizational sites themselves. In most cases, an endpoint needs to 84 connect to only one security gateway to gain access to internal 85 resources. However, several situations may require an endpoint to 86 connect to additional security gateways of the same organization. 87 For example, this may happen when the organization manages multiple 88 entry points to the internal network for failover, or when the 89 endpoint needs to connect to hosts lying behind multiple security 90 gateways. 92 Connection to each of the security gateways requires mutual 93 authentication between the endpoint and the security gateway. The 94 IKEv2 Protocol [RFC4306] allows the use of legacy authentication 95 systems along with authentications that use public key signatures and 96 shared secrets. Legacy strong authentication systems typically 97 require active participation of the user operating the endpoint. For 98 example, methods using a token may require the user to enter a 99 passcode appearing on the token. IKE authentication methods may 100 require such an intervention as well, e.g., entering a password to 101 get access to a certificate file. Even if the endpoint was 102 previously authenticated by one security gateway, any connection to 103 an additional security gateway will require additional 104 authentication. 106 This document describes an extension to IKEv2 that allows an endpoint 107 to perform an IKE exchange to request a "short term certificate". 108 This short term certificate can be used in subsequent IKE 109 authentications to prove to a security gateway that the endpoint was 110 already authenticated by another trusted security gateway, thereby 111 allowing the authentication of the endpoint without user 112 intervention. The basic idea is to allow a security gateway to vouch 113 for the authenticity of an endpoint, thereby saving the need for user 114 involvement in the recurring authentication. 116 The protocol presented here is similar in concept to the one 117 suggested in the now expired draft of the Pre-IKE Credential 118 Provisioning Protocol [PIC]. PIC was proposed as a form of using 119 legacy authentication methods to enable certificate enrollment for 120 use in IKE. While PIC is performed outside of IKE, the protocol we 121 propose is an extension to IKEv2 used by an entity already 122 authenticated in a former IKEV2 exchange. 124 A work in progress [I-D.ohba-preauth-ps] focuses on pre- 125 authentication in the context of EAP [RFC3748], and is mainly driven 126 by the need to provide seamless and fast inter-technology handovers 127 for mobile devices. In contrast, short-term certificates do not 128 assume a common EAP server behind the gateways, and do not require 129 gateways to communicate with each other. 131 2. Preliminaries 133 The methods described in this document depend on trust between 134 security gateways. A security gateway should be able to verify that 135 a certificate presented by an endpoint was indeed issued by another 136 trusted security gateway, and to establish the integrity of the 137 presented certificate. The way this trust is established and 138 maintained (e.g., PKI [RFC3280]) lies outside the scope of this 139 document. 141 3. Short-Term Certificate Usage 143 The use of Short-Term Certificates takes the following form: 145 1. At any time following a successful mutual authentication and the 146 establishment of an IKE SA, an endpoint MAY send a request for a 147 Short Term Certificate. 149 2. Subject to security gateway configuration and policy, the gateway 150 issues a Short Term Certificate and sends it back to the 151 endpoint. The lifetime of the Short Term Certificate will 152 typically be the timeout until re-authentication is required. 153 According to the IKEv2 specification, a gateway that does not 154 support this type of request will send an empty CFG_REPLY or a 155 response with no CFG_REPLY at all. 157 3. During the validity period of the certificate, the endpoint MAY 158 use the certificate for signature-based authentication with any 159 security gateway that trusts the issuer of the certificate, 160 instead of using any default authentication method. Note that 161 any security gateway that conforms to IKEv2 specification can 162 authenticate this certificate, whether or not it conforms to the 163 Short Term Credentials specification. 165 The following sections describe the message exchange required for 166 issuing a Short-Term Certificate, how the certificate is used and how 167 expiration of a certificate should be handled. 169 4. Short-Term Certificates Issue Exchange 171 At any point after the security gateway authenticated the endpoint 172 and the IKE SA was established, the endpoint MAY initiate a Short 173 Term Certificate request and send it to the security gateway. A 174 Short Term Certificate may also be requested from a security gateway 175 which did not authenticate the endpoint directly, but authenticated 176 it based on another Short Term Certificate (i.e., authentication with 177 Short Term Certificates is transitive). 179 A Short Term Certificate Request is sent as a Configuration Payload 180 of type CFG_REQUEST in an INFORMATIONAL exchange. The reply is sent 181 as a Configuration Payload of type CFG_REPLY in an INFORMATIONAL 182 exchange. The following attribute types have been defined for the 183 Short Term Certificate issue exchange: 185 +----------------------+-------+----------------+-----------------+ 186 | Attribute Type | Value | Request Length | Response Length | 187 +----------------------+-------+----------------+-----------------+ 188 | STC_CERTIFICATE_TYPE | TBD+0 | 1 octet | 1 octet | 189 | STC_ROOT_CA | TBD+1 | 0 or more | -- | 190 | STC_CERTREQ | TBD+2 | 0 or more | -- | 191 | STC_CHAIN | TBD+3 | 1 octet | -- | 192 | STC_CERTIFICATE | TBD+4 | -- | 0 or more | 193 | STC_LIFETIME | TBD+5 | -- | 4 octets | 194 +----------------------+-------+----------------+-----------------+ 196 o STC_CERTIFICATE_TYPE - An encoding of a certificate type which 197 indicates the type of certificate provided in the STC_CERTIFICATE 198 attribute, according to the Certificate Encoding values provided 199 for the Certificate Payload in Sec. 3.6 of IKEv2 [RFC4306] . In a 200 request message, this field defines the encodings of all requested 201 attributes. In a reply message, this value MUST be identical to 202 the one appearing in the request, and MUST determine the encodings 203 of all included attributes. For interoperability, all 204 implementations MUST support type 1, "PKCS #7 wrapped X.509 205 certificate" [RFC2315]. 207 o STC_ROOT_CA - MUST NOT be sent in a reply. An encoding 208 identifying the Certificate Authority on whose trust chain a 209 signature is requested. If STC_CERTIFICATE_TYPE is type 1, this 210 field MUST contain the Binary Distinguished Encoding Rules (DER) 211 encoding of an ASN.1 X.500 Distinguished Name [ITU.X501.1993] that 212 identifies a Certificate Authority. In a request message, one 213 trusted Certificate Authority MAY be provided. 215 o STC_CERTREQ - MUST NOT be sent in a reply. An encoding of a 216 certification request, including the requesting endpoint identity, 217 a public key to be associated with this identity, and a proof of 218 possession of the matching private key. If STC_CERTIFICATE_TYPE 219 is type 1, this field MUST contain a PKCS #10 [RFC2986] encoded 220 certification request. 222 o STC_CHAIN - MUST NOT be sent in a reply. A flag used to denote 223 whether a single certificate is required (NO_CHAIN=0) or a full 224 certificate chain (FULL_CHAIN=1). If the client already possesses 225 the certificates required to construct a certificate chain, it may 226 set this variable to NO_CHAIN (0) in the request message to save 227 bandwidth. This flag is a hint: the responder MAY reply with a 228 full chain even if no chain was requested, and vice versa. 230 o STC_CERTIFICATE - MUST NOT be sent in a request. Whenever the 231 request is accepted and a short term certificate is issued, the 232 responder MUST set this attribute with an encoding of the issued 233 certificate according to the type that appeared in the request 234 message, and set the STC_LIFETIME attribute in accordance with the 235 certificate contents. If STC_CERTIFICATE_TYPE is type 1, this 236 field MUST contain a PKCS #7 encoding of the issued certificate. 238 o STC_LIFETIME - MUST NOT be sent in a request. In the reply 239 message, this attribute contains the remaining lifetime of the 240 Short Term Certificate, in seconds. This value can be used by the 241 endpoint to keep track of the Short Term Certificate expiration 242 time, so a new certificate can be requested and the old 243 certificate deleted by expiration. This attribute is required 244 since the client cannot rely on the notBefore and notAfter fields 245 supplied in the certificate: there is no guarantee that the 246 endpoint's clock is synchronized with the security gateway's 247 clock. In addition, the notBefore field may be set several 248 minutes prior to certificate creation time (to compensate for 249 minor clock deviation between security gateways). 251 The endpoint MAY use a fixed private/public key pair for all Short 252 Term Credential exchanges, or create a different key pair for each 253 Short Term Certificate in use. Security considerations (see the 254 Security Considerations section (Section 8)) may apply in case a 255 fixed private/public key pair is used for more than one Short Term 256 Credential exchange. 258 In case a security gateway receives a malformed Short Term 259 Certificate request, it MUST send a notification payload of type 260 INVALID_SYNTAX in the response message. If the Short Term 261 Certificate request is rejected for any other reason (e.g., gateway 262 configuration or security policy), the gateway MUST send a 263 notification payload of type STC_UNSUPPORTED in the response message 264 to inform that the request was rejected. In both cases, the 265 CFG_REPLY payload MUST either be sent empty or dropped altogether 266 from the response. 268 When a security gateway issues a Short Term Certificate, the 269 following restrictions apply: 271 o The Short Term Certificate MUST be a legal IKEv2 certificate, per 272 IKEv2 [RFC4306] and PKI4IPsec 273 [I-D.ietf-pki4ipsec-ikecert-profile]. 275 o It is RECOMMENDED that the private/public keys used by the 276 security gateway to issue Short Term Certificates will be 277 different from those used for authenticating the security gateway. 279 o The gateway MUST check that the identity appearing in the received 280 certification request matches the identity of the endpoint 281 associated with the IKE SA used to perform the exchange (similarly 282 to the specification in PKI4IPsec 283 [I-D.ietf-pki4ipsec-ikecert-profile]). In case of a mismatch, the 284 gateway MUST reject the request. In other words, a gateway MUST 285 NOT issue a certificate which identifies a different entity than 286 the one associated with the IKE SA. 288 o The gateway MUST verify the signature in the certification 289 request, to assert that the client possesses the private key 290 corresponding to the public key being certified. In case of an 291 invalid signature, the gateway MUST reject the request. 293 o The Short Term Certificate expiration time MUST NOT exceed the 294 remaining time for repeated authentication [RFC4478], if such time 295 is defined. If there is no defined time for repeated 296 authentication, the gateway MUST limit the expiration time to no 297 more than 24 hours. Note that IKE SA lifetime is irrelevant for 298 determining Short Term Certificates expiration time, since 299 rekeying IKE SAs does not require re-authentication. 301 o If the security gateway has a signing key that was certified by 302 the root CA described in the Short Term Certificate request, then 303 it MUST use this key to sign the Short Term Certificate. If no 304 signing key matches a requested root CA, then the gateway MUST 305 reject the request. If no STC_ROOT_CA was specified in the 306 request, the security gateway MAY choose the root CA to use. 307 Alternatively, it MAY reject the request. 309 o The issued certificate MUST be of the type requested in a 310 STC_CERTIFICATE_TYPE attribute of the request message. In other 311 words, the STC_CERTIFICATE_TYPE attribute has the same value in 312 the request and the response. 314 o The key associated with the subject of the certificate MUST be the 315 public key sent in the Short Term Certificate request. 317 o When a full certificate chain should be sent to the endpoint, it 318 is RECOMMENDED to make use of "Hash and URL" formats for the 319 certificate chain to keep message size below the maximum UDP 320 message size supported. 322 5. Using Short-Term Certificates 324 Once an endpoint acquired a Short Term Certificate from a security 325 gateway, this certificate can be used for signature based 326 authentication with any other security gateway that trusts the 327 issuing gateway. 329 Note that certificate specifications are flexible enough to allow for 330 transferring proprietary authentication-related information from the 331 issuing security gateway to any other security gateway which will 332 validate the Short Term Certificate. Such proprietary extensions and 333 their implications on security are out of the scope of this document. 335 6. Expiration of Short-Term Certificates 337 An endpoint SHOULD NOT keep a Short Term Certificate after its 338 expiration time was reached, since trying to use this certificate 339 would result in a failed authentication. It is RECOMMENDED to 340 refrain from using a Short Term Certificate for authentication if its 341 expiration time is very close (e.g., less than ten minutes), since a 342 repeated authentication [RFC4478] may take place once the newly 343 created IKE SA is expired. 345 When the user terminates communications with a site ("logs off"), the 346 Short Term Credentials associated with the site MUST be destroyed. 347 Typically this will occur in conjunction with deletion of IKE_SAs 348 with the site. However IKE_SAs may also be deleted without explicit 349 user action. 351 7. IANA Considerations 353 The proposed extension requires IANA allocations for the "TBD" 354 attribute types and the STC_UNSUPPORTED notify message type described 355 in Section 4. 357 8. Security Considerations 359 Since certificates are widely used as long term credentials, special 360 care should be taken to prevent abuse of Short Term Certificates 361 which would lead to security risks. 363 The expiration time of the Short Term Certificate can never be later 364 than a time limit defined for repeated authentication. This 365 restriction prevents the use of Short Term Credentials for artificial 366 extension of the IKE SA validity time, bypassing actual 367 authentication of the user. 369 The Short Term Certificate issue exchange is protected with the 370 established IKE SA. This maintains the confidentiality and the 371 integrity of the exchange. Impersonating a security gateway would 372 not allow a malicious user to abuse a Short Term Certificate and 373 impersonate a valid user. Even if a malicious user was able to 374 acquire a Short Term Certificate of another user, knowledge of the 375 private key is still required to be able to use the Short Term 376 Certificate successfully. 378 Lifetime of private/public key pairs needs to be considered if the 379 same key pair is used for more than a single Short Term Certificate 380 exchange. The client SHOULD generate new private/public key pairs at 381 regular intervals, in accordance with security policy. This is the 382 same situation as applies in all certificate request protocols: The 383 same private/public key pair can be used in multiple requests, but 384 its lifetime should nonetheless be considered limited. 386 9. Operational Considerations 388 Because of the granularity of Short Term Certificates expiration 389 time, the administrator MUST prevent clock rollback on gateways and 390 synchronize the clocks of mutually trusting security gateways. For 391 example, the NTPv3 [RFC1305] or SNTPv4 [RFC4330] protocols can be 392 implemented to provide this functionality. When such protocols are 393 implemented to provide gateway synchronization, they SHOULD be 394 properly secured to prevent attacks based on desynchronizing security 395 gateway clocks. 397 10. Acknowledgements 399 11. References 400 11.1. Normative References 402 [I-D.ietf-pki4ipsec-ikecert-profile] 403 Korver, B., "The Internet IP Security PKI Profile of 404 IKEv1/ISAKMP, IKEv2, and PKIX", 405 draft-ietf-pki4ipsec-ikecert-profile-12 (work in 406 progress), February 2007. 408 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 409 Requirement Levels", BCP 14, RFC 2119, March 1997. 411 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 412 RFC 4306, December 2005. 414 11.2. Informative References 416 [I-D.ohba-preauth-ps] 417 Ohba, Y., "EAP Pre-authentication Problem Statement", 418 draft-ohba-preauth-ps-01 (work in progress), March 2007. 420 [ITU.X501.1993] 421 International Telecommunications Union, "Information 422 Technology - Open Systems Interconnection - The Directory: 423 Models", ITU-T Recommendation X.501, ISO Standard 9594-2, 424 1993. 426 [PIC] Sheffer, Y., Krawczyk , H., and B. Aboba , "PIC, A Pre-IKE 427 Credential Provisioning Protocol, Internet-draft 428 (expired), draft-ietf-ipsra-pic-06.txt", October 2002. 430 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 431 Specification, Implementation", RFC 1305, March 1992. 433 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 434 Version 1.5", RFC 2315, March 1998. 436 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 437 Request Syntax Specification Version 1.7", RFC 2986, 438 November 2000. 440 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 441 X.509 Public Key Infrastructure Certificate and 442 Certificate Revocation List (CRL) Profile", RFC 3280, 443 April 2002. 445 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 446 Levkowetz, "Extensible Authentication Protocol (EAP)", 447 RFC 3748, June 2004. 449 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 450 Internet Protocol", RFC 4301, December 2005. 452 [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 453 for IPv4, IPv6 and OSI", RFC 4330, January 2006. 455 [RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange 456 (IKEv2) Protocol", RFC 4478, April 2006. 458 Authors' Addresses 460 Arik Friedman 461 Technion IIT 462 Haifa 32000 463 Israel 465 Email: arikf@cs.technion.ac.il 467 Yaron Sheffer 468 Check Point Software Technologies Ltd. 469 5 Hasolelim st. 470 Tel Aviv 67897 471 Israel 473 Email: yaronf at checkpoint dot com 475 Ariel Shaqed (Scolnicov) 476 Correlix, Inc. 477 Herzelia Pituah 478 Israel 480 Email: ariel.shaqed+ietf@gmail.com 482 Full Copyright Statement 484 Copyright (C) The IETF Trust (2007). 486 This document is subject to the rights, licenses and restrictions 487 contained in BCP 78, and except as set forth therein, the authors 488 retain all their rights. 490 This document and the information contained herein are provided on an 491 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 492 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 493 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 494 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 495 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 496 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 498 Intellectual Property 500 The IETF takes no position regarding the validity or scope of any 501 Intellectual Property Rights or other rights that might be claimed to 502 pertain to the implementation or use of the technology described in 503 this document or the extent to which any license under such rights 504 might or might not be available; nor does it represent that it has 505 made any independent effort to identify any such rights. Information 506 on the procedures with respect to rights in RFC documents can be 507 found in BCP 78 and BCP 79. 509 Copies of IPR disclosures made to the IETF Secretariat and any 510 assurances of licenses to be made available, or the result of an 511 attempt made to obtain a general license or permission for the use of 512 such proprietary rights by implementers or users of this 513 specification can be obtained from the IETF on-line IPR repository at 514 http://www.ietf.org/ipr. 516 The IETF invites any interested party to bring to its attention any 517 copyrights, patents or patent applications, or other proprietary 518 rights that may cover technology that may be required to implement 519 this standard. Please address the information to the IETF at 520 ietf-ipr@ietf.org. 522 Acknowledgment 524 Funding for the RFC Editor function is provided by the IETF 525 Administrative Support Activity (IASA).