One document matched: draft-dang-nistkdf-00.txt
Personal Draft
Internet Draft Q. Dang
Document: draft-dang-nistkdf-00.txt T. Polk
NIST
Expires: April 19 2006 October 2005
Hash-Based Key Derivation
draft-dang-nistkdf-00.txt
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.
For potential updates to the above required-text see:
http://www.ietf.org/ietf/1id-guidelines.txt
Copyright Notice
Copyright (C) The Internet Society (2005).
This Internet-Draft will expire on April 19, 2006.
Abstract
Dang Expires April 2006 [Page 1]
Hash-Based Key Derivation October 2005
This draft specifies a Key Derivation Function (KDF) used to derive
secret symmetric keying material for participating parties from a
secret value and application specific information. The KDF is based
on concatenation and a secure hash function. The length in bits of
secret keying material that can be generated by the KDF is limited to
(2**32 - 1) times the length in bits of the output block of the hash
function. The derived keying material is a concatenation of the
outputs of the hashing operations. Inputs to the hash function are
incremented counter values, one for each separate hashing operation;
the secret value; an optional algorithm identifier; identifiers for
the participating parties, and optional protocol specific
information.
Conventions used in this document
The Key Word "Secret Value" and "Key Derivation" are defined as
follows:
Secret Value: A value known only by the two communicating parties
that will be used as input to the key derivation function. This value
may be established out-of-band, selected by one of the communicating
parties, or by the two communicating parties.
Key Derivation: The process by which keying material (e.g., one or
more symmetric keys) is derived from a secret value and other non-
secret information.
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 [KEYWORDS].
Table of Contents
1. Introduction...................................................3
2. Hash-Based Key Derivation Function (HKDF)......................3
2.1 HKDF Inputs and Fixed Values...............................4
2.2 HKDF Algorithm.............................................7
3. Supported Scenarios............................................8
3.1 Secret Values Established out of band......................8
3.2 Initiator Selected Secret Values...........................8
3.3 Key agreements.............................................9
4. Security Considerations.......................................11
5. Acknowledgments...............................................13
6. References....................................................13
6.1 Normative References......................................13
6.2 Informative References....................................13
7. Author's Addresses............................................14
Dang Expires April 2006 [Page 2]
Hash-Based Key Derivation October 2005
8. IANA Considerations...........................................14
9. Disclaimer of Validity........................................14
10. Copyright Statement..........................................14
1. Introduction
The security of a secret key shared between two participating parties
may be reduced if the secret key is used for each and every secure
channel or transaction. However, it is inconvenient and inefficient
if communicating parties must maintain different secret values for
each secure channel or transaction. Therefore, it is necessary to
have an algorithm that can be used to derive distinct secret keying
material for each and every secure channel or transaction from a
single secret value shared between participating parties. This
algorithm should be strong and standardized to overcome compatibility
issues in communication protocols and their implementations.
The hash-based key derivation function (HKDF) specified in this draft
is used to derive secret keying material from a secret value. The
output from the HKDF is only used for secret keying material, such as
a symmetric key used for data encryption or message integrity, a
secret initialization vector, etc. Non-secret keying material (such
as a non-secret initialization vector) is not generated using the
secret value.
The algorithm is based on a secret value, a hash function (e.g., SHA-
256) [1], and concatenation.
This document defines a general algorithm for hash-based key
derivation in Section 2 that can be used with any secure hash
function. This algorithm includes mandatory and optional steps,
enabling the algorithm to support a broad range of protocols and
applications. Section 3 describes four general scenarios to
establish secret values that are used in the HKDF algorithm, and
indicates when the optional steps are required. Section 4 presents
security considerations with respect to the application of the HKDF.
2. Hash-Based Key Derivation Function (HKDF)
The HKDF is constructed from a secure hash function H. HKDF accepts
three mandatory inputs and two optional inputs, and uses one
implementation dependent fixed value.
The mandatory HKDF inputs are a secret value that is a bit string,
contextual information, and the length of the desired key material.
The optional HKDF inputs are an algorithm identifier and information
shared between the participating parties. The implementation
dependent fixed value describes the length of the output from the
Dang Expires April 2006 [Page 3]
Hash-Based Key Derivation October 2005
hash function H. The HKDF inputs and implementation-dependent fixed
values are described in detail in Section 2.1.
The HKDF algorithm returns either the desired key material, or an
error. The complete HKDF algorithm is presented in Section 2.2.
2.1 HKDF Inputs and Fixed Values
2.1.1 Secret Value (SV)
The secret value, SV, is a bit string known only to the participating
parties. The secret value can be either a fixed or variable length
bit string. To ensure that the secret value input by both parties is
the same when the secret value is variable in length, it is preceded
by a fixed length string that indicates the length (in bytes) of the
secret value.
Let SVData be a secret bit string that is generated from one of
Supported Scenarios described in Section 3 of this document. When
SVData is a fixed length bit string, SV has the form:
SV = SVData
When SVData is a variable length bit string, SV has the form:
SV = SVLen || SVData,
where SVData is a variable-length bit string of (eight-bit) bytes,
while SVLen is a fixed length bit string that indicates the length
(in bytes) of SVData.
Protocols that reference this specification MUST specify the format
of the secret value and the lengths of the fixed length quantities:
a) Where SV is a fixed length string, the protocol MUST specify the
length; and
b) Where SV is a variable length string, the protocol MUST specify
the size of SVLen.
SV may be established through off-line or on-line processes,
depending upon the scenario. See Section 3 for supported scenarios
through which the SV can be established. The security strength of SV
is determined by the method used to generate SV (see Section 4).
2.1.2 algorithmID
The algorithmID is an optional input. If present, the algorithmID
indicates how the derived keying material will be parsed and for
which algorithm(s) the derived keying material will be used. For
example, algorithmID might indicate that bits 1-80 are to be used as
Dang Expires April 2006 [Page 4]
Hash-Based Key Derivation October 2005
an 80-bit HMAC key, and that bits 81-208 are to be used as a 128-bit
AES key.
An algorithmID consists of two concatenated values: algorithmLen and
algorithmOID. The algorithmLen is a fixed length bit string that
indicates the length (in bytes) of algorithmOID. The algorithmOID
is an ASCII string representing an ASN.1 object identifier.
Protocols that reference this specification MUST specify whether
algorithmID is omitted or included. If included, the protocol MUST
specify the length of algorithmLen and the semantics of any
recognized object identifiers.
2.1.3 contextID
The contextID is a mandatory input. The contextID is a string formed
by concatenating strings IDU and IDV; IDU and IDV identify the
participating parties. Each of the bit strings IDU and IDV is an
identifier (that is, a bit string that is associated with a person,
device or organization). An identifier may be an identifying name or
may be something more abstract (for example, an IP address and
timestamp), depending on the application. IDU identifies the
initiator of the session or transaction, and IDV identifies the
responder, as specified by the protocol.
There are two formats for the contextID: a fixed-length contextID
format and a variable-length contextID format.
The fixed-length contextID format is used where IDU and IDV are
fixed-length bit strings, and contextID consists of IDU || IDV.
The variable-length contextID format is used where IDU and IDV are
variable-length bit strings. In this case, contextID has the form:
IDlenU || IDU || IDlenV || IDV
where IDU and IDV are variable-length strings (of eight-bit bytes)
that serve as the identifiers of the participating parties, and
IDLenU and IDlenV are fixed-length bit strings that indicate the
lengths (in eight-bit bytes) of IDU and IDV, respectively.
Party U shall be the initiator, and party V shall be the responder,
as assigned by the protocol.
Protocols that reference this specification MUST specify the
following information:
(a) Which party is defined as the initiator and which is the
responder;
Dang Expires April 2006 [Page 5]
Hash-Based Key Derivation October 2005
(b) The contextID format (i.e., fixed length vs. variable length);
(c) The source of the identifiers IDU and IDV (e.g., "use the dns
name of the server as IDV"). The values for IDU and IDV should
be as specific as feasible for their intended use, and each
shall be represented in a protocol-specific format.
(d) The lengths for the fixed-length quantities and the acceptable
range of variable-length quantities. For the fixed-length
contextID, the fixed-length quantities are IDU and IDV. For
the variable-length contextID, the fixed-length quantities are
IDlenU and IDlenV. (Note that the maximum length of IDU and
IDV in the variable-length format must be consistent with the
size of IDlenU and IDlenV.
2.1.4 keydatalen
Keydatalen is a mandatory input. Keydatalen is an integer that
indicates the length in bits of the secret keying material to be
generated; keydatalen shall be less than or equal to hashlen x (2**32
- 1).
2.1.5 SharedInfo
SharedInfo is an optional input. SharedInfo is a bit string that
consists of the concatenation of a (protocol-specific) sequence of
substrings of data shared by the parties generating the secret keying
material. Where the substring has a fixed length, the substring is
composed of just the substring data. Where a substring has variable
length, the substring has the form Datalen || Data, where Data is a
variable length string (of eight bit bytes), and Datalen is a fixed-
length string that indicates the length (in bytes) of Data.
Protocols may specify a SharedInfo field that contains fixed length
substrings, variable length substrings, or a combination. For each
substring of SharedInfo, a protocol using this key derivation
function must specify which of these data representations is used.
The protocol must also specify the lengths for all fixed-length
quantities.
SharedInfo ::= Substring-1 || Substring-2 ||... Substring-n
n is a number of substrings in SharedInfo.
Substring-i ::= FixedSubString / VariableSubString
i is an integer between 1 and n.
FixedSubstring ::= Fixed-length bit string
VariableSubstring::= Datalen || Data
Datalen ::= fixed-length string
Data ::= variable length eight-bit byte string.
Dang Expires April 2006 [Page 6]
Hash-Based Key Derivation October 2005
2.1.6 Hash function H and hashlen
In addition to the input values, the HKDF algorithm depends upon the
base hash function and one related implementation-dependent fixed
value. The base hash function, or H, is used to derive blocks of
secret keying material. The implementation-dependent fixed value is
hashlen. The hashlen is an integer value that indicates the length
in bits of the output block of H.
Protocols that reference this specification SHOULD support multiple
hash functions and MAY support negotiation between the communicating
parties for the selection of H.
2.2 HKDF Algorithm
1. reps = ceiling ( keydatalen / hashlen )
2. If reps > (2**32 - 1), then ABORT: output "Invalid" and stop.
3. Initialize a 32-bit, big-endian bit string counter as 00000001 in
hexadecimal.
4. For i = 1 to reps by 1, do the following:
a. Compute Hash-i = H (counter || SV {|| algorithmID} ||
contextID {|| SharedInfo}).
b. Increment counter (modulo 2**32), treating it as an unsigned
32-bit integer.
5. Let Hhash be set to Hash-reps if (keydatalen / hashlen) is an
integer; otherwise, let Hhash be set to the (keydatalen mod
hashlen) leftmost bits of Hash-reps.
6. Set DerivedKeyingMaterial = Hash-1 || Hash-2 || ... || Hash-(reps-
1)|| Hhash.
Output:
The bit string DerivedKeyingMaterial of length keydatalen bits (or
"Invalid").
Any scheme attempting to call this key derivation function with
keydatalen greater than or equal to hashlen * (2**32 - 1) shall
output "Invalid" and stop without outputting DerivedKeyingMaterial.
Dang Expires April 2006 [Page 7]
Hash-Based Key Derivation October 2005
3. Supported Scenarios
This section describes three general scenarios to generate secret
values for the hash-based key derivation function (HKDF): (1) two
parties have previously established a secret value using an out-of-
band method; (2) the initiator selects a secret value and conveys it
to a recipient using standard key transport mechanisms; and (3) two
parties use one of key agreement protocols to establish a secret
value.
3.1 Secret Values Established out of band
In the first scenario, two parties establish a secret value through
out-of-band channels. The secret value is used with the HKDF to
establish session-specific or transaction-specific keying material in
future communications. To ensure that distinct keying material is
generated, a protocol supporting secret values established out of
band MUST include SharedInfo substrings with transaction or
application specific information unique to this execution of the
protocol. For online protocols, the SharedInfo substrings SHOULD
include information contributed by both the initiator and the
recipient.
3.2 Initiator Selected Secret Values
In the second scenario, one party (the initiator) wishes to establish
a secure communication channel with a second party (the recipient).
The recipient has a long term asymmetric key pair for use during key
establishment, and the public key is known to the initiator. (Most
commonly, the public key is distributed in an X.509 certificate.) The
initiator generates a secret value and encrypts the secret value by
using an asymmetric cryptographic technique (e.g., RSA) with the
recipient's public key, and then sends the secret value to the other
party. The recipient decrypts it to get the secret value; the secret
value is used with the HKDF to generate session-specific or
transaction-specific keying material.
The initiator can authenticate the recipient's public key using the
recipient's certificate. There is no authentication of the initiator
in this case unless the initiator (a) signs the transmitted secret
value using a long term asymmetric (digital signature) key pair, or
(b) is a registered party to the recipient with an ID and associated
password. The initiator can encrypt the ID and password by using the
recipient's public key, and then sends the resulting ciphertext to
the recipient. This is a common scenario in SSL or TLS sessions, with
the initiator being a client and the recipient being a server.
Protocols that support initiator-selected secret values SHOULD
include SharedInfo substrings with transaction or application
Dang Expires April 2006 [Page 8]
Hash-Based Key Derivation October 2005
specific information. For online protocols, the SharedInfo
substrings SHOULD include information contributed by the recipient.
This prevents an initiator from predicting the output from the HKDF.
The computation MAY include SharedInfo substrings contributed by the
initiator.
3.3 Key agreements
In the third scenario, two parties use asymmetric cryptography (e.g.,
Diffie-Hellman or Menezes-Qu-Vanstone) to establish a secret value
using a key agreement scheme. The secret value is used with the HKDF
to establish a session-specific or transaction-specific keying
material. The secret value should be deleted immediately after
computing the keying material.
The parties may use previously registered long-term asymmetric keys
(a.k.a. static keys), or generate a new ephemeral (temporary, one-
time) key pair specifically for this iteration of the key agreement
process. Where one or more static keys are employed, the HKDF
supplements the secret value with application specific and/or session
specific information to ensure that the keying material is distinct.
3.3.1 Static-Static Key Agreement
When both participating parties have complementary static key pairs
for key agreement, the secret value SV may be computed. For example,
if both parties have Diffie-Hellman static key pairs with the same
parameters, or elliptic curve key pairs over the same curve, the
secret value SV may be generated using the appropriate key agreement
algorithm. In general, the public keys associated with these static
key pairs are conveyed in X.509 certificates. After SV is generated,
it is then used to derive the keying material.
Since both key pairs are static, this method will always produce the
same SV for any pair of participants. Similarly, the contextID will
be the same for these participants for any given protocol or
application. To ensure that distinct keying material is derived, a
protocol using static-static key agreement MUST include SharedInfo
substrings that are unique to this session or execution of a
protocol. The SharedInfo substrings MUST include information
contributed by both the initiator and the recipient.
3.3.2 Static-Ephemeral Key Agreement
Static-ephemeral key agreement may be performed when one participant
(the recipient) has a static key pair, and the other party (the
intiator) has the ability to generate ephemeral keys. The
recipient's static public key is known to the initiator through an
X.509 certificate or other secure mechanism. In this case, the
Dang Expires April 2006 [Page 9]
Hash-Based Key Derivation October 2005
initator generates a complementary ephemeral key pair (e.g., a
temporary or one-time Diffie-Hellman key pair that is generated with
the same parameters that were used to generate the recipient's static
key pair) for this specific session or transaction. The initiator
sends its ephemeral public key to the recipient. Each party uses its
own key pair, the other party's public key and the appropriate key
agreement algorithm to generate the secret value. The secret value is
then used to derive the keying material. (The initiator should
delete the ephemeral private key after generating the secret value.)
This method is vulnerable to man-in-the-middle attacks if the
initiator's ephemeral public key is not verified, because an attacker
can impersonate the initiator in this key agreement protocol.
Authentication of the ephemeral public key can be obtained if the
initiator has a digital signature key pair with a corresponding
public key certificate. In this case, the initiator signs its
ephemeral public key using its digital signature private key, and
then sends the ephemeral public key and the signature to the
recipient, who can use the corresponding public key certificate to
verify the signature and authenticate the initiator.
The HKDF computation SHOULD include SharedInfo substrings with
transaction or application-specific information.
3.3.3 Ephemeral-Ephemeral Key Agreement
Ephemeral-ephemeral key agreement may be performed when neither
participant has a long term key pair, but each participant has the
ability to generate ephemeral key pairs. In this case, the
participants agree on parameters (or curves), then each participant
generates an ephemeral key pair using those parameters.
Each participant signs the public key from its ephemeral key
agreement key pair using its private digital signature key and sends
the ephemeral public key and the signature to the other party. The
receiver uses the sending party's corresponding public key to verify
the signature. In general, the receiver will use the sender's public
key certificate to authenticate the participant.
Each party uses its own ephemeral key pair, the other party's
ephemeral public key and the appropriate key agreement algorithm to
compute the secret value. The ephemeral private keys should be
erased after computation of the secret value.
This option appears to be the most secure of the key agreement
options because it results in a temporary, authenticated ephemeral
key.
Dang Expires April 2006 [Page 10]
Hash-Based Key Derivation October 2005
For this scenario, the SharedInfo substrings are optional, since the
participants generate a new secret value based on new ephemeral key
pairs for each execution of the HKDF. Each participant contributes
randomness through their key generation process.
3.3.4 Anonymous Key Agreement
In this scenario, the ephemeral-ephemeral key agreement algorithm is
used without authentication. That is, the participants agree on
public (e.g., Diffie-Hellman) parameters and exchange ephemeral
public keys but do not sign the messages. This protocol results in a
secret value and derived keying material in the same way as
ephemeral-ephemeral key agreement.
This approach is vulnerable to man-in-the-middle attacks, in which
the attacker conducts anonymous key agreement exchanges with both
parties. The public key agreement parameters can be delivered
physically or electronically.
As above, the SharedInfo substrings are optional, since the
participants generate a new secret value based on new ephemeral key
pairs for each execution of the HKDF.
4. Security Considerations
Special care should be taken to protect the secret value and to limit
its exposure over time. When a secret value is no longer needed, it
should be destroyed.
If a session key generated from the HKDF is compromised, an attacker
can decrypt all the messages exchanged in the session. However, this
provides no information about the other session keys or the original
secret value. [CSD1]Previous and subsequent session keys generated
from the same secret value in different HKDF computations are still
secure. This provides a much stronger security than using the same
key in all sessions. This is one of the main purposes to use the HKDF
algorithm as described above.
If the original secret value is somehow compromised, then an attacker
can derive all the session keying material and use it to access all
messages in all communication sessions between the two parties that
used that secret value. So, the original secret value must be
strongly resistant to brute-force attacks and kept securely.
The strength of a key derived using the HKDF is limited by the
security strength of the hash function H, the strength of the secret
value, and the length of the derived key itself.
Dang Expires April 2006 [Page 11]
Hash-Based Key Derivation October 2005
Assuming that the output of the HKDF cannot be differentiated from
random data, the best attack against a derived key is a brute force
attack. The work factor to perform such an attack is 2**n, where n
is the length of the derived key.
When used in HKDF, the work factor to attack a secure hash function
is 2**h, where h is the length of the output.
Calculating the security strength of the secret value is more
complex. In this specification, secret values may be distributed
out-of-band, obtained through key agreement, or user selecte[CSD2]d.
Security Strengths of secret values depend on the mechanisms used to
generate and distribute them, as well as their sizes.
Where secret values are randomly chosen (for out-of-band distribution
or during the user selection process), the security strengths of
these secret values describe their resistance to brute-force attacks.
If a strong random number generator is employed, the security
strength depends [CSD3]only on the length s (in bits) of the secret
value. In this case, the strength of the secret value is
approximately 2**s.
Where secret values are generated using key agreement schemes, the
security strengths of the secret values depend on the key agreement
algorithm used and the security strength of the asymmetric keys. For
example, 1024 bit Diffie-Hellman has an approximate security strength
of 80 bits. That is, a secret value derived using 1024 bit Diffie-
Hellman is roughly equivalent to an 80 bit randomly generated secret
value. Similarly, a secret value derived using 163 bit elliptic
curve Diffie-Hellman is roughly equivalent to an 80 bit randomly
generated secret value. For additional information regarding the
strength of values obtained using key agreemnent schemes, see [4] and
[6].
Where secret values are established out-of-band, the process used to
distribute the secret values must prevent disclosure to other
parties. Assuming that the secret values are established securely,
the strength of the derived key material depends upon the security
strength s of the secret value and the length m of a derived key.
The security level achieved is 2**y where y is the smallest of the
values m and s.
In the "Initiator Selected Secret Values" scenario, the secret value
is selected by one party and encrypted under an asymmetric key (e.g.,
the secret value is sent to the recipient using RSA transport). The
security strength of the derived keying material is the minimum of
the security strength of the asymmetric key pair, the strength of the
secret value, and the length of a derived key. For example, 1024 bit
RSA provides approximately 80 bits of security. The strength of a
Dang Expires April 2006 [Page 12]
Hash-Based Key Derivation October 2005
derived key is limited to 80 bits even if the secret value itself has
a security strength greater than 80 bits. Therefore, all components
MUST have a security strength equal to or greater than the target
security strength for the keying material to be derived. See [5] for
guidance on random number generation and [6] for information on the
cryptographic strength of asymmetric cryptography.
5. Acknowledgments
The protocol defined in this document is based largely on work by
Elaine Barker, Don Johnson, and Miles Smid in [2]. This document
also borrows some text from [3] by C. Michael Chernick, Charles
Edington III, Mathew J. Fanto. John Kelsey, Morrie Dworkin, and
Bill Burr provided invaluable advice and assistance.
6. References
6.1 Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
6.2 Informative References
1 National Institute of Standards and Technology, "Secure Hash
Standard (SHS)", Federal Information Processing Standards
Publication 180-2, August 2002.
2 National Institute of Standards and Technology, "Recommendation
for Pair-Wise Key Establishment Schemes Using Discrete Logarithm
Cryptography", NIST Special Publication 800-56, July, 2005.
3 National Institute of Standards and Technology, "Guidelines for
the Selection and Use of Transport Layer Security (TLS)
Implementation", NIST Special Publication 800-52, June, 2005.
4 Orman H. and Hoffman P., "Determining Strengths For Public Keys
Used For Exchanging Symmetric Keys", RFC 3766, April 2004.
5 National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", Federal Information Processing
Standards Publication 186-2, October 2001.
6 National Institute of Standards and Technology, "Recommendation
for Key Management", NIST Special Publication 800-57, August
2005.
7 National Institute of Standards and Technology, "Electronic
Authentication Guideline", NIST Special Publication 800-63, June
2004.
Dang Expires April 2006 [Page 13]
Hash-Based Key Derivation October 2005
7. Author's Addresses
Quynh Dang
National Institute of Standards and Technology
100 Bureau Drive, Mail Stop 8930
Gaithersburg, MD 20899-8930
Email: quynh.dang@nist.gov
Tim Polk
National Institute of Standards and Technology
100 Bureau Drive, Mail Stop 8930
Gaithersburg, MD 20899-8930
Email: tim.polk@nist.gov
8. IANA Considerations
None.
9. Disclaimer of Validity
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.
10. Copyright Statement
Copyright (C) The Internet Society (2005).
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.
Dang Expires April 2006 [Page 14]
Hash-Based Key Derivation October 2005
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.
This Internet-Draft will expire on April 19, 2006.
Dang Expires - April 2006 [Page 15] | PAFTECH AB 2003-2026 | 2026-04-23 05:54:59 |