RFC 3830
MIKEY: Multimedia Internet KEYing
7. Transport protocols
MIKEY MAY be integrated within session establishment protocols. Currently, integration of MIKEY within SIP/SDP and RTSP is defined in [KMASDP]. MIKEY MAY use other transports, in which case how MIKEY is transported over such a transport protocol has to be defined.8. Groups
What has been discussed up to now is not limited to single peer-to- peer communication (except for the DH method), but can be used to distribute group keys for small-size interactive groups and simple one-to-many scenarios. Section 2.1. describes the scenarios in the focus of MIKEY. This section describes how MIKEY is used in a group scenario (though, see also Section 4.3 for issues related to authorization).
8.1. Simple one-to-many
++++ |S | | | ++++ | --------+-------------- - - | | | v v v ++++ ++++ ++++ |A | |B | |C | | | | | | | ++++ ++++ ++++ Figure 8.1. Simple one-to-many scenario. In the simple one-to-many scenario, a server is streaming to a small group of clients. RTSP or SIP is used for the registration and the key management set up. The streaming server acts as the Initiator of MIKEY. In this scenario, the pre-shared key or public key transport mechanism will be appropriate in transporting the same TGK to all the clients (which will result in common TEKs for the group). Note, if the same TGK/TEK(s) should be used by all the group members, the streaming server MUST specify the same CSB_ID and CS_ID(s) for the session to all the group members. As the communication may be performed using multicast, the members need a common security policy if they want to be part of the group. This limits the possibility of negotiation. Furthermore, the Initiator should carefully consider whether to request the verification message in reply from each receiver, as this may result in a certain load for the Initiator itself as the group size increases.8.2. Small-size interactive group
As described in the overview section, for small-size interactive groups, one may expect that each client will be in charge for setting up the security for its outgoing streams. In these scenarios, the pre-shared key or the public-key transport method is used.
++++ ++++ |A | -------> |B | | | <------- | | ++++ ++++ ^ | | ^ | | | | | | ++++ | | | --->|C |<--- | ------| |------ ++++ Figure 8.2. Small-size group without a centralized controller. One scenario may then be that the client sets up a three-part call, using SIP. Due to the small size of the group, unicast SRTP is used between the clients. Each client sets up the security for its outgoing stream(s) to the others. As for the simple one-to-many case, the streaming client specifies the same CSB_ID and CS_ID(s) for its outgoing sessions if the same TGK/TEK(s) is used for all the group members.9. Security Considerations
9.1. General
Key management protocols based on timestamps/counters and one- roundtrip key transport have previously been standardized, for example ISO [ISO1, ISO2]. The general security of these types of protocols can be found in various articles and literature, c.f. [HAC, AKE, LOA]. No chain is stronger than its weakest link. If a given level of protection is wanted, then the cryptographic functions protecting the keys during transport/exchange MUST offer a security corresponding to at least that level. For instance, if a security against attacks with a complexity 2^96 is wanted, then one should choose a secure symmetric cipher supporting at least 96 bit keys (128 bits may be a practical choice) for the actual media protection, and a key transport mechanism that provides equivalent protection, e.g., MIKEY's pre-shared key transport with 128 bit TGK, or RSA with 1024 bit keys (which according to [LV] corresponds to the desired 96 bit level, with some margin). In summary, key size for the key-exchange mechanism MUST be weighed against the size of the exchanged TGK so that it at least offers the required level. For efficiency reasons, one SHOULD also avoid a
security overkill, e.g., by not using a public key transport with public keys giving a security level that is orders of magnitude higher than length of the transported TGK. We refer to [LV] for concrete key size recommendations. Moreover, if the TGKs are not random (or pseudo-random), a brute force search may be facilitated, again lowering the effective key size. Therefore, care MUST be taken when designing the (pseudo-) random generators for TGK generation, see [FIPS][RAND]. For the selection of the hash function, SHA-1 with 160-bit output is the default one. In general, hash sizes should be twice the "security level", indicating that SHA-1-256, [SHA256], should be used for the default 128-bit level. However, due to the real-time aspects in the scenarios we are treating, hash sizes slightly below 256 are acceptable, as the normal "existential" collision probabilities would be of secondary importance. In a Crypto Session Bundle, the Crypto Sessions can share the same TGK as discussed earlier. From a security point of view, to satisfy the criterion in case the TGK is shared, the encryption of the individual Crypto Sessions are performed "independently". In MIKEY, this is accomplished by having unique Crypto Session identifiers (see also Section 4.1) and a TEK derivation method that provides cryptographically independent TEKs to distinct Crypto Sessions (within the Crypto Session Bundle), regardless of the security protocol used. Specifically, the key derivations, as specified in Section 4.1, are implemented by a pseudo-random function. The one used here is a simplified version of that used in TLS [TLS]. Here, only one single hash function is used, whereas TLS uses two different functions. This choice is motivated by the high confidence in the SHA-1 hash function, and by efficiency and simplicity of design (complexity does not imply security). Indeed, as shown in [DBJ], if one of the two hashes is severely broken, the TLS PRF is actually less secure than as if a single hash had been used on the whole key, as is done in MIKEY. In the pre-shared key and public-key schemes, the TGK is generated by a single party (Initiator). This makes MIKEY somewhat more sensitive if the Initiator uses a bad random number generator. It should also be noted that neither the pre-shared nor the public-key scheme provides perfect forward secrecy. If mutual contribution or perfect forward secrecy is desired, the Diffie-Hellman method is to be used. Authentication (e.g., signatures) in the Diffie-Hellman method is required to prevent man-in-the-middle attacks.
Forward/backward security: if the TGK is exposed, all generated TEKs are compromised. However, under the assumption that the derivation function is a pseudo-random function, disclosure of an individual TEK does not compromise other (previous or later) TEKs derived from the same TGK. The Diffie-Hellman mode can be considered by cautious users, as it is the only one that supports so called perfect forward secrecy (PFS). This is in contrast to a compromise of the pre-shared key (or the secret key of the public key mode), where future sessions and recorded sessions from the past are then also compromised. The use of random nonces (RANDs) in the key derivation is of utmost importance to counter off-line pre-computation attacks. Note however that update messages re-use the old RAND. This means that the total effective key entropy (relative to pre-computation attacks) for k consecutive key updates, assuming the TGKs and RAND are each n bits long, is about L = n*(k+1)/2 bits, compared to the theoretical maximum of n*k bits. In other words, a 2^L work effort MAY enable an attacker to get all k n-bit keys, which is better than brute force (except when k = 1). While this might seem like a defect, first note that for a proper choice of n, the 2^L complexity of the attack is way out of reach. Moreover, the fact that more than one key can be compromised in a single attack is inherent to the key exchange problem. Consider for instance a user who, using a fixed 1024-bit RSA key, exchanges keys and communicates during a one or two year lifetime of the public key. Breaking this single RSA key will enable access to all exchanged keys and consequently the entire communication of that user over the whole period. All the pre-defined transforms in MIKEY use state-of-the-art algorithms that have undergone large amounts of public evaluation. One of the reasons for using the AES-CM from SRTP [SRTP], is to have the possibility of limiting the overall number of different encryption modes and algorithms, while offering a high level of security at the same time.9.2. Key lifetime
Even if the lifetime of a TGK (or TEK) is not specified, it MUST be taken into account that the encryption transform in the underlying security protocol can in some way degenerate after a certain amount of encrypted data. It is not possible to here state universally applicable, general key lifetime bounds; each security protocol should define such maximum amount and trigger a re-keying procedure before the "exhaustion" of the key. For example, according to SRTP [SRTP] the TEK, together with the corresponding TGK, MUST be changed at least every 2^48 SRTP packet.
Still, the following can be said as a rule of thumb. If the security protocol uses an "ideal" b-bit block cipher (in CBC mode, counter mode, or a feedback mode, e.g., OFB, with full b-bit feedback), degenerate behavior in the crypto stream, possibly useful for an attacker, is (with constant probability) expected to occur after a total of roughly 2^(b/2) encrypted b-bit blocks (using random IVs). For security margin, re-keying MUST be triggered well in advance compared to the above bound. See [BDJR] for more details. For use of a dedicated stream cipher, we refer to the analysis and documentation of said cipher in each specific case.9.3. Timestamps
The use of timestamps, instead of challenge-responses, requires the systems to have synchronized clocks. Of course, if two clients are not synchronized, they will have difficulties in setting up the security. The current timestamp based solution has been selected to allow a maximum of one roundtrip (i.e., two messages), but still provide a reasonable replay protection. A (secure) challenge- response based version would require at least three messages. For a detailed description of the timestamp and replay handling in MIKEY, see Section 5.4. Practical experiences of Kerberos and other timestamp-based systems indicate that it is not always necessary to synchronize the terminals over the network. Manual configuration could be a feasible alternative in many cases (especially in scenarios where the degree of looseness is high). However, the choice must be made carefully with respect to the usage scenario.9.4. Identity Protection
User privacy is a complex matter that to some extent can be enforced by cryptographic mechanisms, but also requires policy enforcement and various other functionalities. One particular facet of privacy is user identity protection. However, identity protection was not a main design goal for MIKEY. Such a feature will add more complexity to the protocol and was therefore not chosen to be included. As MIKEY is anyway proposed to be transported over, e.g., SIP, the identity may be exposed by this. However, if the transporting protocol is secured and also provides identity protection, MIKEY might inherit the same feature. How this should be done is for future study.
9.5. Denial of Service
This protocol is resistant to Denial of Service attacks in the sense that a Responder does not construct any state (at the key management protocol level) before it has authenticated the Initiator. However, this protocol, like many others, is open to attacks that use spoofed IP addresses to create a large number of fake requests. This may for example, be solved by letting the protocol transporting MIKEY do an IP address validity test. The SIP protocol can provide this using the anonymous authentication challenge mechanism (specified in Section 22.1 of [SIP]). It is highly RECOMMENDED to include IDr in the Initiator's message. If not included, its absence can be used for DoS purposes (the largest DoS-impact being on the public key and DH methods), where a message intended for other entities is sent to the target. In fact, the target may verify the signature correctly due to the fact that the Initiator's ID is correct and the message is actually signed by the claimed Initiator (e.g., by re-directing traffic from another session). However, in the public key method, the envelop key and the MAC will ensure that the message is not accepted (still, compared to a normal faked message, where the signature verification would detect the problem, one extra public key decryption is needed to detect the problem in this case). In the DH method, a message would be accepted (without detecting the error) and a response (and state) would be created for the malicious request. As also discussed in Section 5.4, the tradeoff between time synchronization and the size of the replay cache may be affected in case of for example, a flooding DoS attack. However, if the recommendations of using a dynamic size of the replay cache are followed, it is believed that the client will in most cases be able to handle the replay cache. Of course, as the replay cache decreases in size, the required time synchronization is more restricted. However, a bigger problem during such an attack would probably be to process the messages (e.g., verify signatures/MACs) due to the computational workload this implies.9.6. Session Establishment
It should be noted that if the session establishment protocol is insecure, there may be attacks on this that will have indirect security implications on the secured media streams. This however only applies to groups (and is not specific to MIKEY). The threat is
that one group member may re-direct a stream from one group member to another. This will have the same implication as when a member tries to impersonate another member, e.g., by changing its IP address. If this is seen as a problem, it is RECOMMENDED that a Data Origin Authentication (DOA) scheme (e.g., digital signatures) be applied to the security protocol. Re-direction of streams can of course be done even if it is not a group. However, the effect will not be the same as compared to a group where impersonation can be done if DOA is not used. Instead, re-direction will only deny the receiver the possibility of receiving (or just delay) the data.10. IANA Considerations
This document defines several new name spaces associated with the MIKEY payloads. This section summarizes the name spaces for which IANA is requested to manage the allocation of values. IANA is requested to record the pre-defined values defined in the given sections for each name space. IANA is also requested to manage the definition of additional values in the future. Unless explicitly stated otherwise, values in the range 0-240 for each name space SHOULD be approved by the process of IETF consensus and values in the range 241-255 are reserved for Private Use, according to [RFC2434]. The name spaces for the following fields in the Common header payload (from Section 6.1) are requested to be managed by IANA (in bracket is the reference to the table with the initially registered values): * version * data type (Table 6.1.a) * Next payload (Table 6.1.b) * PRF func (Table 6.1.c). This name space is between 0-127, where values between 0-111 should be approved by the process of IETF consensus and values between 112-127 are reserved for Private Use. * CS ID map type (Table 6.1.d) The name spaces for the following fields in the Key data transport payload (from Section 6.2) are requested to be managed by IANA: * Encr alg (Table 6.2.a) * MAC alg (Table 6.2.b)
The name spaces for the following fields in the Envelope data payload (from Section 6.3) are requested to be managed by IANA: * C (Table 6.3) The name spaces for the following fields in the DH data payload (from Section 6.4) are requested to be managed by IANA: * DH-Group (Table 6.4) The name spaces for the following fields in the Signature payload (from Section 6.5) are requested to be managed by IANA: * S type (Table 6.5) The name spaces for the following fields in the Timestamp payload (from Section 6.6) are requested to be managed by IANA: * TS type (Table 6.6) The name spaces for the following fields in the ID payload and the Certificate payload (from Section 6.7) are requested to be managed by IANA: * ID type (Table 6.7.a) * Cert type (Table 6.7.b) The name spaces for the following fields in the Cert hash payload (from Section 6.8) are requested to be managed by IANA: * Hash func (Table 6.8) The name spaces for the following fields in the Security policy payload (from Section 6.10) are requested to be managed by IANA: * Prot type (Table 6.10) For each security protocol that uses MIKEY, a set of unique parameters MAY be registered. From Section 6.10.1. * SRTP Type (Table 6.10.1.a) * SRTP encr alg (Table 6.10.1.b) * SRTP auth alg (Table 6.10.1.c)
* SRTP PRF (Table 6.10.1.d) * FEC order (Table 6.10.1.e) The name spaces for the following fields in the Error payload (from Section 6.12) are requested to be managed by IANA: * Error no (Table 6.12) The name spaces for the following fields in the Key data payload (from Section 6.13) are requested to be managed by IANA: * Type (Table 6.13.a). This name space is between 0-16, which should be approved by the process of IETF consensus. * KV (Table 6.13.b). This name space is between 0-16, which should be approved by the process of IETF consensus. The name spaces for the following fields in the General Extensions payload (from Section 6.15) are requested to be managed by IANA: * Type (Table 6.15).10.1. MIME Registration
This section gives instructions to IANA to register the application/mikey MIME media type. This registration is as follows: MIME media type name : application MIME subtype name : mikey Required parameters : none Optional parameters : version version: The MIKEY version number of the enclosed message (e.g., 1). If not present, the version defaults to 1. Encoding Considerations : binary, base64 encoded Security Considerations : see section 9 in this memo Interoperability considerations : none Published specification : this memo11. Acknowledgments
The authors would like to thank Mark Baugher, Ran Canetti, Martin Euchner, Steffen Fries, Peter Barany, Russ Housley, Pasi Ahonen (with his group), Rolf Blom, Magnus Westerlund, Johan Bilien, Jon-Olov Vatn, Erik Eliasson, and Gerhard Strangar for their valuable feedback.
12. References
12.1. Normative References
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [NAI] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998. [PSS] PKCS #1 v2.1 - RSA Cryptography Standard, RSA Laboratories, June 14, 2002, www.rsalabs.com [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [SHA-1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995. [SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real Time Transport Protocol", RFC 3711, March 2004. [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [X.509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [AESKW] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
12.2. Informative References
[AKE] Canetti, R. and H. Krawczyk, "Analysis of Key-Exchange Protocols and their use for Building Secure Channels", Eurocrypt 2001, LNCS 2054, pp. 453-474, 2001. [BDJR] Bellare, M., Desai, A., Jokipii, E., and P. Rogaway, "A Concrete Analysis of Symmetric Encryption: Analysis of the DES Modes of Operation", in Proceedings of the 38th Symposium on Foundations of Computer Science, IEEE, 1997, pp. 394-403. [BMGL] Hastad, J. and M. Naslund: "Practical Construction and Analysis of Pseduo-randomness Primitives", Proceedings of Asiacrypt 2001, LNCS. vol 2248, pp. 442-459, 2001. [DBJ] Johnson, D.B., "Theoretical Security Concerns with TLS use of MD5", Contribution to ANSI X9F1 WG, 2001. [FIPS] "Security Requirements for Cryptographic Modules", Federal Information Processing Standard Publications (FIPS PUBS) 140-2, December 2002. [GKMARCH] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Group Key Management Architecture", Work in Progress. [GDOI] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003. [GSAKMP] Harney, H., Colegrove, A., Harder, E., Meth, U., and R. Fleischer, "Group Secure Association Key Management Protocol", Work in Progress. [HAC] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook of Applied Cryptography", CRC press, 1996. [IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [ISO1] ISO/IEC 9798-3: 1997, Information technology - Security techniques - Entity authentication - Part 3: Mechanisms using digital signature techniques. [ISO2] ISO/IEC 11770-3: 1997, Information technology - Security techniques - Key management - Part 3: Mechanisms using digital signature techniques.
[ISO3] ISO/IEC 18014 Information technology - Security techniques - Time-stamping services, Part 1-3. [KMASDP] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "Key Management Extensions for SDP and RTSP", Work in Progress. [LOA] Burrows, Abadi, and Needham, "A logic of authentication", ACM Transactions on Computer Systems 8 No.1 (Feb. 1990), 18-36. [LV] Lenstra, A. K. and E. R. Verheul, "Suggesting Key Sizes for Cryptosystems", http://www.cryptosavvy.com/suggestions.htm [NTP] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992. [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999. [RAND] Eastlake, 3rd, D., Crocker, S., and J. Schiller, "Randomness Requirements for Security", RFC 1750, December 1994. [RTSP] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [SDP] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [SHA256] NIST, "Description of SHA-256, SHA-384, and SHA-512", http://csrc.nist.gov/encryption/shs/sha256-384-512.pdf [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [TLS] Dierks, T. and C. Allen, "The TLS Protocol - Version 1.0", RFC 2246, January 1999.
Appendix A. MIKEY - SRTP Relation
The terminology in MIKEY differs from the one used in SRTP as MIKEY needs to be more general, nor is tight to SRTP only. Therefore, it might be hard to see the relations between keys and parameters generated in MIKEY and those used by SRTP. This section provides some hints on their relation. MIKEY | SRTP ------------------------------------------------- Crypto Session | SRTP stream (typically with related SRTCP stream) Data SA | input to SRTP's crypto context TEK | SRTP master key The Data SA is built up by a TEK and the security policy exchanged. SRTP may use an MKI to index the TEK or TGK (the TEK is then derived from the TGK that is associated with the corresponding MKI), see below.A.1. MIKEY-SRTP Interactions
In the following, we give a brief outline of the interface between SRTP and MIKEY and the processing that takes place. We describe the SRTP receiver side only, the sender side will require analogous interfacing. 1. When an SRTP packet arrives at the receiver and is processed, the triple <SSRC, destination address, destination port> is extracted from the packet and used to retrieve the correct SRTP crypto context, hence the Data SA. (The actual retrieval can, for example, be done by an explicit request from the SRTP implementation to MIKEY, or, by the SRTP implementation accessing a "database", maintained by MIKEY. The application will typically decide which implementation is preferred.) 2. If an MKI is present in the SRTP packet, it is used to point to the correct key within the SA. Alternatively, if SRTP's <From, To> feature is used, the ROC||SEQ of the packet is used to determine the correct key. 3. Depending on whether the key sent in MIKEY (as obtained in step 2) was a TEK or a TGK, there are now two cases. - If the key obtained in step 2 is the TEK itself, it is used directly by SRTP as a master key.
- If the key instead is a TGK, the mapping with the CS_ID
(internal to MIKEY, Section 6.1.1) allows MIKEY to compute the
correct TEK from the TGK as described in Section 4.1 before
SRTP uses it.
If multiple TGKs (or TEKs) are sent, it is RECOMMENDED that each TGK
(or TEK) be associated with a distinct MKI. It is RECOMMENDED that
the use of <From, To> in this scenario be limited to very simple
cases, e.g., one stream only.
Besides the actual master key, other information in the Data SA
(e.g., transform identifiers) will of course also be communicated
from MIKEY to SRTP.
Authors' Addresses
Jari Arkko Ericsson Research 02420 Jorvas Finland Phone: +358 40 5079256 EMail: jari.arkko@ericsson.com Elisabetta Carrara Ericsson Research SE-16480 Stockholm Sweden Phone: +46 8 50877040 EMail: elisabetta.carrara@ericsson.com Fredrik Lindholm Ericsson Research SE-16480 Stockholm Sweden Phone: +46 8 58531705 EMail: fredrik.lindholm@ericsson.com Mats Naslund Ericsson Research SE-16480 Stockholm Sweden Phone: +46 8 58533739 EMail: mats.naslund@ericsson.com Karl Norrman Ericsson Research SE-16480 Stockholm Sweden Phone: +46 8 4044502 EMail: karl.norrman@ericsson.com
Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.