Network Working Group S. Kelly
Internet-Draft Aruba Wireless Networks
Intended status: Standards Track S. Frankel
Expires: April 1, 2007 NIST
September 28, 2006
Using HMAC-SHA-256 With IPsec
draft-kelly-ipsec-ciph-sha2-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 1, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This specification describes the use of the SHA-256 algorithm in
conjunction with HMAC as a data origin authentication and integrity
verification mechanism for the IPsec AH, ESP, and IKEv2 protocols,
and also as a PRF for IKEv2. Two output truncation lengths are
specified for data origin authentication and integrity verification
usage, with the corresponding algorithms designated as HMAC-SHA-256-
128 and HMAC-SHA-256-192. No truncation is specified for PRF usage,
Kelly & Frankel Expires April 1, 2007 [Page 1]
Internet-Draft Using HMAC-SHA-256 With IPsec September 2006
and the resulting algorithm is designated as HMAC-SHA-PRF-256.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The HMAC-SHA-256 Algorithms . . . . . . . . . . . . . . . . . 3
2.1. Keying Material . . . . . . . . . . . . . . . . . . . . . 3
2.1.1. Data Origin Authentication and Integrity
Verification Usage . . . . . . . . . . . . . . . . . . 3
2.1.2. Pseudo-Random Function (PRF) Usage . . . . . . . . . . 4
2.1.3. Randomness and Key Strength . . . . . . . . . . . . . 4
2.1.4. Key Distribution . . . . . . . . . . . . . . . . . . . 4
2.1.5. Refreshing Keys . . . . . . . . . . . . . . . . . . . 4
2.2. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Truncation . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Using HMAC-SHA-256 As a PRF in IKEv2 . . . . . . . . . . . 6
2.5. Interactions with the ESP or IKEv2 Cipher Mechanisms . . . 6
2.6. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . 6
3. Security Considerations . . . . . . . . . . . . . . . . . . . 10
3.1. HMAC Key Length vs Truncation Length . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Kelly & Frankel Expires April 1, 2007 [Page 2]
Internet-Draft Using HMAC-SHA-256 With IPsec September 2006
1. Introduction
This document specifies the use of SHA-256 [SHA2-1] combined with
HMAC [HMAC] as a data origin authentication and integrity
verification mechanism for the IPsec AH [AH], ESP [ESP], and IKEv2
[IKEv2] protocols. For flexibility, two output truncation lengths
are specified for the authentication-related variants, with the
corresponding algorithms designated as HMAC-SHA-256-128 and HMAC-SHA-
256-192. In addition, this document specifies use of the underlying
HMAC-SHA-256 algorithm (without truncation) as a PRF within IKEv2,
and that variant is designated as HMAC-SHA-PRF-256. These algorithms
are collectively referred to below as "the HMAC-SHA-256 algorithms."
The goal of the PRF variant is to provide a secure pseudo-random
function suitable for generation of keying material and other
protocol-specific numeric quantities, while the goal of the
authentication variants is to ensure that packets are authentic and
cannot be modified in transit. The relative security of HMAC-SHA-256
when used in either case is dependent on the scope of distribution
and the unpredictability of the associated secret key. If the key is
not predictable and known only by the source and destination, these
algorithms ensure that only parties holding an identical key can
derive the associated values.
2. The HMAC-SHA-256 Algorithms
[SHA2-1] and [SHA2-2] describe the underlying SHA-256 algorithm,
while [HMAC] describes the HMAC algorithm. The HMAC algorithm
provides a framework for inserting various hashing algorithms such as
SHA-256. The following sections describe the various characteristics
and requirements of the HMAC-SHA-256 algorithms.
2.1. Keying Material
Requirements for keying material vary depending on usage. These
distinctions are described in the following sections.
2.1.1. Data Origin Authentication and Integrity Verification Usage
HMAC-SHA-256 is a secret key algorithm. While no fixed key length is
specified in [HMAC], this specification requires that for use as an
integrity algorithm, a fixed key length of 256-bits MUST be
supported, and key lengths other than 256-bits MUST NOT be supported.
The 256-bit key length is chosen based on the recommendations in
[HMAC] (i.e. key lengths less than the authenticator length decrease
security strength and keys longer than the authenticator length do
not significantly increase security strength).
Kelly & Frankel Expires April 1, 2007 [Page 3]
Internet-Draft Using HMAC-SHA-256 With IPsec September 2006
2.1.2. Pseudo-Random Function (PRF) Usage
IKEv2 uses PRFs for multiple purposes, most notably for generating
keying material and authentication of the IKE_SA. The IKEv2
specification differentiates between PRFs with fixed key sizes and
those with variable key sizes.
When the PRF described in this document is used with IKEv2, it is
considered to have a variable key length, and keys are derived in the
following way (as specified in [HMAC]):
o If the key is exactly 256 bits long, use it as-is.
o If the key has fewer than 256 bits, lengthen it to exactly 256
bits by padding it on the right with zero bits. However, note
that [HMAC] strongly discourages a key length less than 256 bits.
o If the key is 257 bits or longer, shorten it to exactly 256 bits
by computing the SHA2-256 hash of the entire key value, and use
the resulting output value as your HMAC key.
2.1.3. Randomness and Key Strength
[HMAC] discusses requirements for key material, including a
requirement for strong randomness. Therefore, a strong pseudo-random
function MUST be used to generate the required 256-bit key for use
with either HMAC-SHA-256-128 or HMAC-SHA-256-192. At the time of
this writing there are no published weak keys for use with HMAC-SHA-
256.
2.1.4. Key Distribution
[ARCH] describes the general mechanism for obtaining keying material
when multiple keys are required for a single SA (e.g. when an ESP SA
requires a key for confidentiality and a key for authentication). In
order to provide data origin authentication and integrity
verification, the key distribution mechanism must ensure that unique
keys are allocated and that they are distributed only to the parties
participating in the communication.
2.1.5. Refreshing Keys
[HMAC] makes the following recommendation with regard to rekeying:
"Current attacks do not indicate a specific recommended frequency for
key changes ... However, periodic key refreshment is a fundamental
security practice that helps against potential weaknesses of the
function and keys, and limits the damage of an exposed key."
Kelly & Frankel Expires April 1, 2007 [Page 4]
Internet-Draft Using HMAC-SHA-256 With IPsec September 2006
Putting this into perspective, this specification requires 256-bit
keys produced by a strong PRF for use as a MAC. A brute force attack
on such keys would take more years to mount than the universe has
been in existence. On the other hand, weak keys (e.g. dictionary
words) would be dramatically less resistant to attack. It is
important to take this, along with the threat model for your
particular application and the current state of the art with respect
to attacks on SHA-256, into account when determining an appropriate
upper bound for HMAC key lifetimes
2.2. Padding
The HMAC-SHA-256 algorithms operate on 512-bit blocks of data.
Padding requirements are specified in [SHA2-1] and are part of the
SHA-256 algorithm, so if you build SHA-256 according to [SHA2-1], you
do not need to add any additional padding as far as the HMAC-SHA-256
algorithms specified here are concerned. With regard to "implicit
packet padding" as defined in [AH], no implicit packet padding is
required.
2.3. Truncation
The HMAC-SHA-256 algorithms produce a 256-bit authenticator value,
and this 256-bit value can be truncated as described in [HMAC]. When
used as a data origin authentication and integrity verification
algorithm in ESP, AH, or IKEv2, a truncated value using the first 128
or 192 bits MUST be supported. No other authenticator value lengths
are supported by this specification.
Upon sending, the truncated value is stored within the authenticator
field. Upon receipt, the entire 256-bit value is computed and the
first 128 or 192 bits are compared to the value stored in the
authenticator field, depending on whether the negotiated algorithm is
HMAC-SHA-256-128 or HMAC-SHA-256-192.
[HMAC] discusses potential security benefits resulting from
truncation of the output MAC value, and in general, encourages HMAC
users to perform MAC truncation. In the context of IPsec, a minimum
truncation length of 128 bits is selected because it corresponds to
the birthday attack bound, and it simultaneously serves to minimize
the additional bits on the wire resulting from use of this facility.
This specification also defines a truncation length of 192 in order
to provide an alternative to those whose security needs outweigh
their concern for minimizing bits on the wire.
Kelly & Frankel Expires April 1, 2007 [Page 5]
Internet-Draft Using HMAC-SHA-256 With IPsec September 2006
2.4. Using HMAC-SHA-256 As a PRF in IKEv2
The HMAC-SHA-PRF-256 algorithm is identical to HMAC-SHA-256-128 and
HMAC-SHA-256-192 except that variable-length keys are permitted, and
the truncation step is NOT performed. The test vectors below which
are simply labeled HMAC-SHA-256 may be used to validate
implementations of HMAC-SHA-PRF-256.
2.5. Interactions with the ESP or IKEv2 Cipher Mechanisms
As of this writing, there are no known issues which preclude the use
of the HMAC-SHA-256 algorithms with any specific cipher algorithm.
2.6. Test Vectors
The following test cases for HMAC-SHA-256-192 and HMAC-SHA-256-128
include the key, the data, and the resulting HMAC. The values of
keys and data are either hexadecimal numbers (prefixed by "0x") or
ASCII character strings (surrounded by double quotes). If a value is
an ASCII character string, then the HMAC computation for the
corresponding test case DOES NOT include the trailing null character
('\0') of the string. The computed HMAC values are all hexadecimal
numbers.
These test cases were verified using 3 independent implementations:
an HMAC wrapper on top of Aaron Gifford's SHA256 implementation
(http://www.adg.us/computers/sha.html), the BeeCrypt crypto library
(http://beecrypt.sourceforge.net/) and the Nettle cryptographic
library (www.lysator.liu.se/~nisse/nettle). Partial blocks were
padded as specified in [SHA2-1].
Test cases 1 and 2 were taken from the SHA-2 FIPS [SHA2-1] and test
cases 4-10 were borrowed from [HMAC-TEST] with some key sizes adjust-
ed for HMAC-SHA-256. These test cases illustrate HMAC-SHA-256 with
various combinations of input and keysize. All test cases include
the computed HMAC-SHA-256; only those with a keysize of 32 bytes (256
bits) also include the truncated HMAC-SHA-256-128 and HMAC-SHA-256-
192.
Kelly & Frankel Expires April 1, 2007 [Page 6]
Internet-Draft Using HMAC-SHA-256 With IPsec September 2006
Test Case #1: HMAC-SHA-256 with 3-byte input and 32-byte key
Key_len : 32
Key : 0x0102030405060708090a0b0c0d0e0f10
1112131415161718191a1b1c1d1e1f20
Data_len : 3
Data : "abc"
HMAC-SHA-256 : 0xa21b1f5d4cf4f73a4dd939750f7a066a
7f98cc131cb16a6692759021cfab8181
HMAC-SHA-256-128: 0xa21b1f5d4cf4f73a4dd939750f7a066a
HMAC-SHA-256-192: 0xa21b1f5d4cf4f73a4dd939750f7a066a
7f98cc131cb16a66
Test Case #2: HMAC-SHA-256 with 56-byte input and 32-byte key
Key_len : 32
Key : 0x0102030405060708090a0b0c0d0e0f10
1112131415161718191a1b1c1d1e1f20
Data_len : 56
Data : "abcdbcdecdefdefgefghfghighijhijk
ijkljklmklmnlmnomnopnopq"
HMAC-SHA-256 : 0x104fdc1257328f08184ba73131c53cae
e698e36119421149ea8c712456697d30
HMAC-SHA-256-128: 0x104fdc1257328f08184ba73131c53cae
HMAC-SHA-256-192: 0x104fdc1257328f08184ba73131c53cae
e698e36119421149
Kelly & Frankel Expires April 1, 2007 [Page 7]
Internet-Draft Using HMAC-SHA-256 With IPsec September 2006
Test Case #3: HMAC-SHA-256 with 112-byte (multi-block) input
and 32-byte key
Key_len : 32
Key : 0x0102030405060708090a0b0c0d0e0f10
1112131415161718191a1b1c1d1e1f20
Data_len : 112
Data : "abcdbcdecdefdefgefghfghighijhijk
ijkljklmklmnlmnomnopnopqabcdbcde
cdefdefgefghfghighijhijkijkljklm
klmnlmnomnopnopq"
HMAC-SHA-256 : 0x470305fc7e40fe34d3eeb3e773d95aab
73acf0fd060447a5eb4595bf33a9d1a3
HMAC-SHA-256-128: 0x470305fc7e40fe34d3eeb3e773d95aab
HMAC-SHA-256-192: 0x470305fc7e40fe34d3eeb3e773d95aab
73acf0fd060447a5
Test Case #4: HMAC-SHA-256 with 8-byte input and 32-byte key
Key_len : 32
Key : 0x0b repeated 32 times
Data_len : 8
Data : 0x4869205468657265
Data : "Hi There"
HMAC-SHA-256 : 0x198a607eb44bfbc69903a0f1cf2bbdc5
ba0aa3f3d9ae3c1c7a3b1696a0b68cf7
HMAC-SHA-256-128: 0x198a607eb44bfbc69903a0f1cf2bbdc5
HMAC-SHA-256-192: 0x198a607eb44bfbc69903a0f1cf2bbdc5
ba0aa3f3d9ae3c1c
Test Case #5: HMAC-SHA-256 with 28-byte input and 4-byte key
Key_len : 4
Key : "Jefe"
Data_len : 28
Data : "what do ya want for nothing?"
HMAC-SHA-256 : 0x5bdcc146bf60754e6a042426089575c7
5a003f089d2739839dec58b964ec3843
Kelly & Frankel Expires April 1, 2007 [Page 8]
Internet-Draft Using HMAC-SHA-256 With IPsec September 2006
Test Case #6: HMAC-SHA-256 with 50-byte input and 32-byte key
Key_len : 32
Key : 0xaa repeated 32 times
Data_len : 50
Data : 0xdd repeated 50 times
HMAC-SHA-256 : 0xcdcb1220d1ecccea91e53aba3092f962
e549fe6ce9ed7fdc43191fbde45c30b0
HMAC-SHA-256-128: 0xcdcb1220d1ecccea91e53aba3092f962
HMAC-SHA-256-192: 0xcdcb1220d1ecccea91e53aba3092f962
e549fe6ce9ed7fdc
Test Case #7: HMAC-SHA-256 with 50-byte input and 37-byte key
Key_len : 37
Key : 0x0102030405060708090a0b0c0d0e0f10
1112131415161718191a1b1c1d1e1f20
2122232425
Data_len : 50
Data : 0xcd repeated 50 times
HMAC-SHA-256 : 0xd4633c17f6fb8d744c66dee0f8f07455
6ec4af55ef07998541468eb49bd2e917
Test Case #8: HMAC-SHA-256 with 20-byte input and 32-byte key
Key_len : 32
Key : 0x0c repeated 32 times
Data_len : 20
Data : "Test With Truncation"
HMAC-SHA-256 : 0x7546af01841fc09b1ab9c3749a5f1c17
d4f589668a587b2700a9c97c1193cf42
HMAC-SHA-256-128: 0x7546af01841fc09b1ab9c3749a5f1c17
HMAC-SHA-256-192: 0x7546af01841fc09b1ab9c3749a5f1c17
d4f589668a587b27
Kelly & Frankel Expires April 1, 2007 [Page 9]
Internet-Draft Using HMAC-SHA-256 With IPsec September 2006
Test Case #9: HMAC-SHA-256 with 54-byte input and 80-byte key
Key_len : 80
Key : 0xaa repeated 80 times
Data_len : 54
Data : "Test Using Larger Than Block-Size Key -
Hash Key First"
HMAC-SHA-256 : 0x6953025ed96f0c09f80a96f78e6538db
e2e7b820e3dd970e7ddd39091b32352f
Test Case #10: HMAC-SHA-256 with 73-byte (multi-block) input
and 80-byte key
Key_len : 80
Key : 0xaa repeated 80 times
Data_len : 73
Data : "Test Using Larger Than Block-Size Key and
Larger Than One Block-Size Data"
HMAC-SHA-256 : 0x6355ac22e890d0a3c8481a5ca4825bc8
84d3e7a1ff98a2fc2ac7d8e064c3b2e6
3. Security Considerations
In a general sense, the security provided by the HMAC-SHA-256
algorithms is based both upon the strength of SHA-256, and upon the
additional strength derived from the HMAC construct. At the time of
this writing there are no practical cryptographic attacks against
either SHA-256 or HMAC. However, as with any cryptographic
algorithm, an important component of HMAC-SHA-256's strength lies in
the correctness of the algorithm implementation, the security of the
key management mechanism, the strength of the associated secret key,
and upon the correctness of the implementation in all of the
participating systems. This specification contains test vectors to
assist in verifying the correctness of HMAC-SHA-256 code, but these
in no way verify the correctness (or security) of surrounding
security infrastructure.
3.1. HMAC Key Length vs Truncation Length
There are important differences between the security levels afforded
by HMAC-SHA1-96 and the HMAC-SHA-256-128 and HMAC-SHA-256-192
algorithms, but there are also considerations which are somewhat
counter-intuitive. There are two different axes along which we gauge
the security of these algorithms: HMAC output length and HMAC key
length. If we assume the HMAC key is a well-guarded secret which can
only be determined through offline attacks on observed values, and
Kelly & Frankel Expires April 1, 2007 [Page 10]
Internet-Draft Using HMAC-SHA-256 With IPsec September 2006
that its length is less than or equal to the output length of the
underlying hash algorithm, then the key's strength is directly
proportional to its length. And if we assume an adversary has no
knowledge of the HMAC key, then the probability of guessing a correct
MAC value for any given packet is directly proportional to the HMAC
output length.
This specification defines truncation to output lengths of either 128
or 192 bits. It is important to note that at this time, it is not
clear that HMAC-SHA-256 with a truncation length of 128 bits is any
more secure than HMAC-SHA1 with the same truncation length, assuming
the adversary has no knowledge of the HMAC key. This is because in
such cases, the adversary must predict only those bits which remain
after truncation. Since in both cases that output length is the same
(128 bits), the adversary's odds of correctly guessing the value are
also the same in either case: 1 in 2^128. Again, if we assume the
HMAC key remains unknown to the attacker, then only a bias in one of
the algorithms would distinguish one from the other. Currently, no
such bias is known to exist in either HMAC-SHA1 or HMAC-SHA-256.
If, on the other hand, the attacker is focused on guessing the HMAC
key, and we assume that the hash algorithms are indistinguishable
when viewed as PRF's, then the HMAC key length provides a direct
measure of the underlying security: the longer the key, the harder it
is to guess. This means that with respect to passive attacks on the
HMAC key, size matters - and the HMAC-SHA-256 algorithms, with their
256-bit key lengths, provide more security in this regard than HMAC-
SHA1 (with its 160-bit key length).
4. IANA Considerations
For use of HMAC-SHA-256 as a PRF in IKEv2, IANA has assigned the
following IKEv2 Pseudo-random function (type 2) transform identifier:
[TBA-1] for PRF_HMAC_SHA2_256
For the use of the HMAC-SHA-256 algorithms for data origin
authentication and integrity verification in IKEv2, ESP or AH, IANA
has assigned the following IKEv2 integrity (type 3) transform
identifiers:
[TBA-2] for AUTH_HMAC_SHA2_256_128
[TBA-3] for AUTH_HMAC_SHA2_256_192
Kelly & Frankel Expires April 1, 2007 [Page 11]
Internet-Draft Using HMAC-SHA-256 With IPsec September 2006
5. Acknowledgements
Portions of this text were unabashedly borrowed from [HMAC-SHA1], and
also from [XCBC-PRF]. Thanks to Hugo Krawczyk for comments and
recommendations on early revisions of this document, and thanks to
Russ Housley for security-related comments and recommendations.
6. References
6.1. Normative References
[AH] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[ARCH] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
[HMAC-SHA1]
Madsen, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998.
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[SHA2-1] NIST, "Draft FIPS PUB 180-2 'Specifications for the Secure
Hash Standard'", 2001 MAY, <http://csrc.nist.gov/
publications/fips/fips180-2/
fips180-2withchangenotice.pdf>.
[SHA2-2] NIST, "Descriptions of SHA-256, SHA-384, and SHA-512",
2001 MAY,
<http://csrc.nist.gov/cryptval/shs/sha256-384-512.pdf>.
6.2. Informative References
[HMAC-TEST]
Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-
SHA-1", RFC 2202, September 1997.
[XCBC-PRF]
Kelly & Frankel Expires April 1, 2007 [Page 12]
Internet-Draft Using HMAC-SHA-256 With IPsec September 2006
Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
Internet Key Exchange Protocol (IKE)", RFC 4434,
February 2006.
Authors' Addresses
Scott G. Kelly
Aruba Wireless Networks
1322 Crossman Ave
Sunnyvale, CA 94089
US
Email: scott@hyperthought.com
Sheila Frankel
NIST
Bldg. 222 Room B264
Gaithersburg, MD 20899
US
Email: sheila.frankel@nist.gov
Kelly & Frankel Expires April 1, 2007 [Page 13]
Internet-Draft Using HMAC-SHA-256 With IPsec September 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Kelly & Frankel Expires April 1, 2007 [Page 14]