Network Working Group M. Lepinski Request for Comments: 5114 S. Kent Category: Informational BBN Technologies January 2008 Additional Diffie-Hellman Groups for Use with IETF Standards Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
AbstractThis document describes eight Diffie-Hellman groups that can be used in conjunction with IETF protocols to provide security for Internet communications. The groups allow implementers to use the same groups with a variety of security protocols, e.g., SMIME, Secure SHell (SSH), Transport Layer Security (TLS), and Internet Key Exchange (IKE). All of these groups comply in form and structure with relevant standards from ISO, ANSI, NIST, and the IEEE. These groups are compatible with all IETF standards that make use of Diffie-Hellman or Elliptic Curve Diffie-Hellman cryptography. These groups and the associated test data are defined by NIST on their web site [EX80056A], but have not yet (as of this writing) been published in a formal NIST document. Publication of these groups and associated test data, as well as describing how to use Diffie-Hellman and Elliptic Curve Diffie-Hellman for key agreement in all of the protocols cited below, in one RFC, will facilitate development of interoperable implementations and support the Federal Information Processing Standard (FIPS) validation of implementations that make use of these groups.
1. Introduction ....................................................2 2. Additional Diffie-Hellman Groups ................................4 2.1. 1024-bit MODP Group with 160-bit Prime Order Subgroup ......4 2.2. 2048-bit MODP Group with 224-bit Prime Order Subgroup ......4 2.3. 2048-bit MODP Group with 256-bit Prime Order Subgroup ......5 2.4. 192-bit Random ECP Group ...................................6 2.5. 224-bit Random ECP Group ...................................7 2.6. 256-bit Random ECP Group ...................................7 2.7. 384-bit Random ECP Group ...................................8 2.8. 521-bit Random ECP Group ...................................9 3. Using These Groups with IETF Standards ..........................9 3.1. X.509 Certificates .........................................9 3.2. IKE .......................................................10 3.3. TLS .......................................................10 3.4. SSH .......................................................11 3.5. SMIME .....................................................11 4. Security Considerations ........................................12 5. IANA Considerations ............................................13 6. Acknowledgments ................................................13 Appendix A: Test Data .............................................14 A.1. 1024-bit MODP Group with 160-bit Prime Order Subgroup......15 A.2. 2048-bit MODP Group with 224-bit Prime Order Subgroup......15 A.3. 2048-bit MODP Group with 256-bit Prime Order Subgroup......16 A.4. 192-bit Random ECP Group ..................................17 A.5. 224-bit Random ECP Group ..................................18 A.6. 256-bit Random ECP Group ..................................18 A.7. 384-bit Random ECP Group ..................................19 A.8. 521-bit Random ECP Group ..................................19 Normative References ..............................................20 Informative References ............................................20 RFC2409] for use with IKEv1, and several additional D-H groups defined later, e.g., [RFC3526] and [RFC4492].
The initial impetus for the definition of D-H groups (in the IETF) arose in the IPsec (IKE) context, because of the use of an ephemeral, unauthenticated D-H exchange as the starting point for that protocol. RFC 2409 defined five standard Oakley Groups: three modular exponentiation groups and two elliptic curve groups over GF[2^N]. One modular exponentiation group (768 bits - Oakley Group 1) was declared to be mandatory for all IKEv1 implementations to support, while the other four were optional. Sixteen additional groups subsequently have been defined and registered with IANA for use with IKEv1, including eight that have also been registered for use with IKEv2. All of these additional groups are optional in the IKE context. Of the twenty-one groups defined so far for use with IKE, eight are MODP groups (exponentiation groups modulo a prime), ten are EC2N groups (elliptic curve groups over GF[2^N]), and three are ECP groups (elliptic curve groups over GF[P]). The purpose of this document is to provide the parameters and test data for eight additional groups, in a format consistent with existing RFCs along with instructions on how these groups can be used with IETF protocols such as SMIME, SSH, TLS, and IKE. Three of these groups were previously specified for use with IKE [RFC4753], and five of these groups were previously specified for use with TLS [RFC4492]. (The latter document does not provide or reference test data for the specified groups). By combining the specification of all eight groups with test data and instructions for use in a variety of protocols, this document serves as a resource for implementers who may wish to offer the same Diffie-Hellman groups for use with multiple IETF protocols. All of these groups are compatible with applicable ISO [ISO-14888-3], ANSI [X9.62], and NIST [NIST80056A] standards for Diffie-Hellman key exchange. These groups and the associated test data are defined by NIST on their web site [EX80056A], but have not yet (as of this writing) been published in a formal NIST document. Publication of these groups with associated test data as an RFC will facilitate development of interoperable implementations and support FIPS validation of implementations that make use of these groups. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
DSS] and [NIST80056A]. Test data for each group is provided in Appendix A.
The hexadecimal value of the generator is: g = AC4032EF 4F2D9AE3 9DF30B5C 8FFDAC50 6CDEBE7B 89998CAF 74866A08 CFE4FFE3 A6824A4E 10B9A6F0 DD921F01 A70C4AFA AB739D77 00C29F52 C57DB17C 620A8652 BE5E9001 A8D66AD7 C1766910 1999024A F4D02727 5AC1348B B8A762D0 521BC98A E2471504 22EA1ED4 09939D54 DA7460CD B5F6C6B2 50717CBE F180EB34 118E98D1 19529A45 D6F83456 6E3025E3 16A330EF BB77A86F 0C1AB15B 051AE3D4 28C8F8AC B70A8137 150B8EEB 10E183ED D19963DD D9E263E4 770589EF 6AA21E7F 5F2FF381 B539CCE3 409D13CD 566AFBB4 8D6C0191 81E1BCFE 94B30269 EDFE72FE 9B6AA4BD 7B5A0F1C 71CFFF4C 19C418E1 F6EC0179 81BC087F 2A7065B3 84B890D3 191F2BFA The generator generates a prime-order subgroup of size: q = 801C0D34 C58D93FE 99717710 1F80535A 4738CEBC BF389A99 B36371EB
The hexadecimal value of the generator is: g = 3FB32C9B 73134D0B 2E775066 60EDBD48 4CA7B18F 21EF2054 07F4793A 1A0BA125 10DBC150 77BE463F FF4FED4A AC0BB555 BE3A6C1B 0C6B47B1 BC3773BF 7E8C6F62 901228F8 C28CBB18 A55AE313 41000A65 0196F931 C77A57F2 DDF463E5 E9EC144B 777DE62A AAB8A862 8AC376D2 82D6ED38 64E67982 428EBC83 1D14348F 6F2F9193 B5045AF2 767164E1 DFC967C1 FB3F2E55 A4BD1BFF E83B9C80 D052B985 D182EA0A DB2A3B73 13D3FE14 C8484B1E 052588B9 B7D2BBD2 DF016199 ECD06E15 57CD0915 B3353BBB 64E0EC37 7FD02837 0DF92B52 C7891428 CDC67EB6 184B523D 1DB246C3 2F630784 90F00EF8 D647D148 D4795451 5E2327CF EF98C582 664B4C0F 6CC41659 The generator generates a prime-order subgroup of size: q = 8CF83642 A709A097 B4479976 40129DA2 99B1A47D 1EB3750B A308B0FE 64F5FBD3
Group curve parameter B (in hexadecimal): b = 5AC635D8 AA3A93E7 B3EBBD55 769886BC 651D06B0 CC53B0F6 3BCE3C3E 27D2604B The generator for this group is given by: g=(gx,gy) where gx = 6B17D1F2 E12C4247 F8BCE6E5 63A440F2 77037D81 2DEB33A0 F4A13945 D898C296 gy = 4FE342E2 FE1A7F9B 8EE7EB4A 7C0F9E16 2BCE3357 6B315ECE CBB64068 37BF51F5 Group Order (in hexadecimal): n = FFFFFFFF 00000000 FFFFFFFF FFFFFFFF BCE6FAAD A7179E84 F3B9CAC2 FC632551
RFC3279]. The MODP groups defined above MUST be represented via the syntax defined in Section 2.3.3, and the elliptic curve groups via
the syntax defined in Section in 2.3.5 of that RFC. When a Diffie-Hellman public key is encoded in a certificate, if the KeyUsage extension is present, the keyAgreement bits MUST be asserted, and encipherOnly or decipherOnly (but not both) MAY be asserted. RFC4306], and the use of MODP groups with IKEv1 is defined in [RFC2409]. However, in the case of ECP Diffie-Hellman groups, the format of key exchange payloads and the derivation of a shared secret has thus far been specified on a group-by-group basis. For the ECP Diffie-Hellman groups defined in this document, the key exchange payload format and shared key derivation procedure specified in [RFC4753] MUST be used (with both IKEv2 and IKEv1). In order to use a Diffie-Hellman group with IKE, it is required that a transform ID for the group be registered with IANA. The following table provides the Transform IDs of each Diffie-Hellman group described in this document, as registered in both [IANA-IKE] and [IANA-IKE2]. NAME | NUMBER --------------------------------------------------------+--------- 1024-bit MODP Group with 160-bit Prime Order Subgroup | 22 2048-bit MODP Group with 224-bit Prime Order Subgroup | 23 2048-bit MODP Group with 256-bit Prime Order Subgroup | 24 192-bit Random ECP Group | 25 224-bit Random ECP Group | 26 256-bit Random ECP Group | 19 384-bit Random ECP Group | 20 521-bit Random ECP Group | 21 RFC4346]. TLS 1.0, the widely deployed predecessor of TLS 1.1, is specified in [RFC2246] and is the same as TLS 1.1 with respect to the use of (MODP) Diffie-Hellman to compute a pre-Master secret. (Currently, the TLS working group is in the process of producing a specification for TLS 1.2. It is unlikely that TLS 1.2 will make significant changes to the use of Diffie-Hellman, and thus the following will likely also be applicable to TLS 1.2).
A server may employ a certificate containing (fixed) Diffie-Hellman parameters, and likewise for a client using a certificate. Thus, the relevant PKIX RFCs (see 3.1 above) are applicable. Alternatively, a server may send ephemeral Diffie-Hellman parameters in the server key exchange message, where the message signature is verified using an RSA- or DSS-signed server certificate. The details for accomplishing this for MODP Diffie-Hellman groups are provided in [RFC2246]. Use of Elliptic Curve Diffie-Hellman in TLS 1.1 (and 1.0) is defined in [RFC4492]. The elliptic curves in this document appear in the IANA EC Named Curve Registry [IANA-TLS], although the names in the registry are taken from the Standards for Efficient Cryptography Group (SECG) specification [SECG] and differ from the names appearing in NIST publications. The following table provides the EC Named Curve ID for each of the elliptic curves along with both the NIST name and the SECG name for the curve. NAME (NIST) | NUMBER | NAME (SECG) ---------------------------------+--------------+--------------- 192-bit Random ECP Group | 19 | secp192r1 224-bit Random ECP Group | 21 | secp224r1 256-bit Random ECP Group | 23 | secp256r1 384-bit Random ECP Group | 24 | secp384r1 521-bit Random ECP Group | 25 | secp521r1 RFC4253]. That RFC defined two MODP Diffie-Hellman groups, and called for the registration of additional groups via an IANA registry. However, [RFC4419] extended the original model to allow MODP Diffie-Hellman parameters to be transmitted as part of the key exchange messages. Thus, using RFC 4419, no additional specifications (or IANA registry actions) are required to enable use of the MODP groups defined in this document. At this time, no RFC describes the use of Elliptic Curve Diffie-Hellman with SSH. However, [SSH-ECC] provides a description of how to make use of Elliptic Curve Diffie-Hellman with SSH. RFC3852]. For MODP Diffie-Hellman, the appropriate reference is [RFC2631]. This specification calls for a sender to extract the Diffie-Hellman (MODP) parameters from a recipient's certificate, and thus the PKIX specifications for representation of Diffie-Hellman parameters suffice. The sender transmits his public key via the
OriginatorIdentifierorKey field, or via a reference to the sender's certificate. Use of Elliptic Curve Diffie-Hellman in CMS is defined in [RFC3278]. As with use of MODP Diffie-Hellman in the CMS context, the sender is assumed to acquire the recipient's public key and parameters from a certificate. The sender includes his Elliptic Curve Diffie-Hellman public key in the KeyAgreeRecipientInfo originator field. (See Section 8.2 of RFC 3278 for details of the ECC-CMS-SharedInfo). NIST80056A] for more information on selecting secret keys.) When secret keys of an appropriate size are used, an approximation of the strength of each of the Diffie-Hellman groups is provided in the table below. For each group, the table contains an RSA key size and symmetric key size that provide roughly equivalent levels of security. This data is based on the recommendations in [NIST80057]. GROUP | SYMMETRIC | RSA -------------------------------------------+------------+------- 1024-bit MODP with 160-bit Prime Subgroup | 80 | 1024 2048-bit MODP with 224-bit Prime Subgroup | 112 | 2048 2048-bit MODP with 256-bit Prime Subgroup | 112 | 2048 192-bit Random ECP Group | 80 | 1024 224-bit Random ECP Group | 112 | 2048 256-bit Random ECP Group | 128 | 3072 384-bit Random ECP Group | 192 | 7680 521-bit Random ECP Group | 256 | 15360
EX80056A]. In the test data for the three modular exponentiation groups, we use the following notation: xA: The secret key of party A yA: The public key of party A xB: The secret key of party B yB: The public key of party B Z: The shared secret that results from the Diffie-Hellman computation In the test data for the five elliptic curve groups, we use the following notation: dA: The secret value of party A x_qA: The x-coordinate of the public key of party A y_qA: The y-coordinate of the public key of party A dB: The secret value of party B x_qA: The x-coordinate of the public key of party B y_qA: The y-coordinate of the public key of party B x_Z: The x-coordinate of the shared secret that results from the Diffie-Hellman computation y_Z: The y-coordinate of the shared secret that results form the Diffie-Hellman computation
yB = 4DCEE992 A9762A13 F2F83844 AD3D77EE 0E31C971 8B3DB6C2 035D3961 182C3E0B A247EC41 82D760CD 48D99599 970622A1 881BBA2D C822939C 78C3912C 6661FA54 38B20766 222B75E2 4C2E3AD0 C7287236 129525EE 15B5DD79 98AA04C4 A9696CAC D7172083 A97A8166 4EAD2C47 9E444E4C 0654CC19 E28D7703 CEE8DACD 6126F5D6 65EC52C6 7255DB92 014B037E B621A2AC 8E365DE0 71FFC140 0ACF077A 12913DD8 DE894734 37AB7BA3 46743C1B 215DD9C1 2164A7E4 053118D1 99BEC8EF 6FC56117 0C84C87D 10EE9A67 4A1FA8FF E13BDFBA 1D44DE48 946D68DC 0CDD7776 35A7AB5B FB1E4BB7 B856F968 27734C18 4138E915 D9C3002E BCE53120 546A7E20 02142B6C Z = 34D9BDDC 1B42176C 313FEA03 4C21034D 074A6313 BB4ECDB3 703FFF42 4567A46B DF75530E DE0A9DA5 229DE7D7 6732286C BC0F91DA 4C3C852F C099C679 531D94C7 8AB03D9D ECB0A4E4 CA8B2BB4 591C4021 CF8CE3A2 0A541D33 994017D0 200AE2C9 516E2FF5 14577926 9E862B0F B474A2D5 6DC31ED5 69A7700B 4C4AB16B 22A45513 531EF523 D7121207 7B5A169B DEFFAD7A D9608284 C7795B6D 5A5183B8 7066DE17 D8D671C9 EBD8EC89 544D45EC 061593D4 42C62AB9 CE3B1CB9 943A1D23 A5EA3BCF 21A01471 E67E003E 7F8A69C7 28BE490B 2FC88CFE B92DB6A2 15E5D03C 17C464C9 AC1A46E2 03E13F95 2995FB03 C69D3CC4 7FCB510B 6998FFD3 AA6DE73C F9F63869
yB = 575F0351 BD2B1B81 7448BDF8 7A6C362C 1E289D39 03A30B98 32C5741F A250363E 7ACBC7F7 7F3DACBC 1F131ADD 8E03367E FF8FBBB3 E1C57844 24809B25 AFE4D226 2A1A6FD2 FAB64105 CA30A674 E07F7809 85208863 2FC04923 3791AD4E DD083A97 8B883EE6 18BC5E0D D047415F 2D95E683 CF14826B 5FBE10D3 CE41C6C1 20C78AB2 0008C698 BF7F0BCA B9D7F407 BED0F43A FB2970F5 7F8D1204 3963E66D DD320D59 9AD9936C 8F44137C 08B180EC 5E985CEB E186F3D5 49677E80 607331EE 17AF3380 A725B078 2317D7DD 43F59D7A F9568A9B B63A84D3 65F92244 ED120988 219302F4 2924C7CA 90B89D24 F71B0AB6 97823D7D EB1AFF5B 0E8E4A45 D49F7F53 757E1913 Z = 86C70BF8 D0BB81BB 01078A17 219CB7D2 7203DB2A 19C877F1 D1F19FD7 D77EF225 46A68F00 5AD52DC8 4553B78F C60330BE 51EA7C06 72CAC151 5E4B35C0 47B9A551 B88F39DC 26DA14A0 9EF74774 D47C762D D177F9ED 5BC2F11E 52C879BD 95098504 CD9EECD8 A8F9B3EF BD1F008A C5853097 D9D1837F 2B18F77C D7BE01AF 80A7C7B5 EA3CA54C C02D0C11 6FEE3F95 BB873993 85875D7E 86747E67 6E728938 ACBFF709 8E05BE4D CFB24052 B83AEFFB 14783F02 9ADBDE7F 53FAE920 84224090 E007CEE9 4D4BF2BA CE9FFD4B 57D2AF7C 724D0CAA 19BF0501 F6F17B4A A10F425E 3EA76080 B4B9D6B3 CEFEA115 B2CEB878 9BB8A3B0 EA87FEBE 63B6C8F8 46EC6DB0 C26C5D7C
y_Z = 0357DCCD 4C804D0D 8D33AA42 B848834A A5605F9A B0D37239 A115BBB6 47936F50
x_qB = 010E BFAFC6E8 5E08D24B FFFCC1A4 511DB0E6 34BEEB1B 6DEC8C59 39AE4476 6201AF62 00430BA9 7C8AC6A0 E9F08B33 CE7E9FEE B5BA4EE5 E0D81510 C24295B8 A08D0235 y_qB = 00A4 A6EC300D F9E257B0 372B5E7A BFEF0934 36719A77 887EBB0B 18CF8099 B9F4212B 6E30A141 9C18E029 D36863CC 9D448F4D BA4D2A0E 60711BE5 72915FBD 4FEF2695 x_Z = 00CD EA89621C FA46B132 F9E4CFE2 261CDE2D 4368EB56 56634C7C C98C7A00 CDE54ED1 866A0DD3 E6126C9D 2F845DAF F82CEB1D A08F5D87 521BB0EB ECA77911 169C20CC y_Z = 00F9 A7164102 9B7FC1A8 08AD07CD 4861E868 614B865A FBECAB1F 2BD4D8B5 5EBCB5E3 A53143CE B2C511B1 AE0AF5AC 827F60F2 FD872565 AC5CA0A1 64038FE9 80A7E4BD [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999. [RFC3278] Blake-Wilson, S., Brown, D., and P. Lambert, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", RFC 3278, April 2002. [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002. [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003. [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie- Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol", RFC 4419, March 2006. [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, May 2006. [RFC4753] Fu, D. and J. Solinas, "ECP Groups For IKE and IKEv2", RFC 4753, January 2007. [SSH-ECC] Green, J. and D. Stebila, "Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer", Work in Progress, 2007. [IANA-IKE] Internet Assigned Numbers Authority, Internet Key Exchange (IKE) Attributes. http://www.iana.org/assignments/ipsec-registry [IANA-IKE2] IKEv2 Parameters. http://www.iana.org/assignments/ikev2-parameters [IANA-TLS] Internet Assigned Numbers Authority, Transport Layer Security (TLS) Attributes. http://www.iana.org/assignments/tls-parameters [ISO-14888-3] International Organization for Standardization and International Electrotechnical Commission, ISO/IEC 14888-3:2006, Information Technology: Security Techniques: Digital Signatures with Appendix: Part 3 - Discrete Logarithm Based Mechanisms. [DSS] National Institute for Standards and Technology, Digital Signature Standard (DSS), FIPS PUB 186-2, January 2000. http://csrc.nist.gov/publications/fips/index.html
[NIST80056A] National Institute of Standards and Technology, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography," NIST Special Publication 800-56A, March 2006. http://csrc.nist.gov/CryptoToolkit/KeyMgmt.html [EX80056A] National Institute for Standards and Technology, "Examples for NIST 800-56A," May 2007. http://csrc.nist.gov/groups/ST/toolkit/examples.html [NIST80057] National Institute of Standards and Technology, "Recommendation for Key Management - Part 1", NIST Special Publication 800-57. [SECG] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2, 2000, <http://www.secg.org/>. [X9.62] ANSI X9.62-2005, Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA). 2005.
Full Copyright Statement Copyright (C) The IETF Trust (2008). 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, THE IETF TRUST 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 email@example.com.