505 lines
15 KiB
Plaintext
505 lines
15 KiB
Plaintext
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Network Working Group W. Hardaker
|
|||
|
|
Internet-Draft Sparta
|
|||
|
|
Expires: August 25, 2006 February 21, 2006
|
|||
|
|
|
|||
|
|
|
|||
|
|
Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
|
|||
|
|
draft-ietf-dnsext-ds-sha256-05.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.
|
|||
|
|
|
|||
|
|
This Internet-Draft will expire on August 25, 2006.
|
|||
|
|
|
|||
|
|
Copyright Notice
|
|||
|
|
|
|||
|
|
Copyright (C) The Internet Society (2006).
|
|||
|
|
|
|||
|
|
Abstract
|
|||
|
|
|
|||
|
|
This document specifies how to use the SHA-256 digest type in DNS
|
|||
|
|
Delegation Signer (DS) Resource Records (RRs). DS records, when
|
|||
|
|
stored in a parent zone, point to key signing DNSKEY key(s) in a
|
|||
|
|
child zone.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Hardaker Expires August 25, 2006 [Page 1]
|
|||
|
|
|
|||
|
|
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
|
|||
|
|
|
|||
|
|
|
|||
|
|
Table of Contents
|
|||
|
|
|
|||
|
|
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
|||
|
|
2. Implementing the SHA-256 algorithm for DS record support . . . 3
|
|||
|
|
2.1. DS record field values . . . . . . . . . . . . . . . . . . 3
|
|||
|
|
2.2. DS Record with SHA-256 Wire Format . . . . . . . . . . . . 3
|
|||
|
|
2.3. Example DS Record Using SHA-256 . . . . . . . . . . . . . . 4
|
|||
|
|
3. Implementation Requirements . . . . . . . . . . . . . . . . . . 4
|
|||
|
|
4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 4
|
|||
|
|
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
|
|||
|
|
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
|
|||
|
|
6.1. Potential Digest Type Downgrade Attacks . . . . . . . . . . 5
|
|||
|
|
6.2. SHA-1 vs SHA-256 Considerations for DS Records . . . . . . 6
|
|||
|
|
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
|
|||
|
|
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
|
|||
|
|
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
|
|||
|
|
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
|
|||
|
|
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
|
|||
|
|
Intellectual Property and Copyright Statements . . . . . . . . . . 9
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Hardaker Expires August 25, 2006 [Page 2]
|
|||
|
|
|
|||
|
|
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
|
|||
|
|
|
|||
|
|
|
|||
|
|
1. Introduction
|
|||
|
|
|
|||
|
|
The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent
|
|||
|
|
zones to distribute a cryptographic digest of a child's Key Signing
|
|||
|
|
Key (KSK) DNSKEY RR. The DS RRset is signed by at least one of the
|
|||
|
|
parent zone's private zone data signing keys for each algorithm in
|
|||
|
|
use by the parent. Each signature is published in an RRSIG resource
|
|||
|
|
record, owned by the same domain as the DS RRset and with a type
|
|||
|
|
covered of DS.
|
|||
|
|
|
|||
|
|
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 [RFC2119].
|
|||
|
|
|
|||
|
|
|
|||
|
|
2. Implementing the SHA-256 algorithm for DS record support
|
|||
|
|
|
|||
|
|
This document specifies that the digest type code [XXX: To be
|
|||
|
|
assigned by IANA; likely 2] is to be assigned to SHA-256 [SHA256]
|
|||
|
|
[SHA256CODE] for use within DS records. The results of the digest
|
|||
|
|
algorithm MUST NOT be truncated and the entire 32 byte digest result
|
|||
|
|
is to be published in the DS record.
|
|||
|
|
|
|||
|
|
2.1. DS record field values
|
|||
|
|
|
|||
|
|
Using the SHA-256 digest algorithm within a DS record will make use
|
|||
|
|
of the following DS-record fields:
|
|||
|
|
|
|||
|
|
Digest type: [XXX: To be assigned by IANA; likely 2]
|
|||
|
|
|
|||
|
|
Digest: A SHA-256 bit digest value calculated by using the following
|
|||
|
|
formula ("|" denotes concatenation). The resulting value is not
|
|||
|
|
truncated and the entire 32 byte result is to used in the
|
|||
|
|
resulting DS record and related calculations.
|
|||
|
|
|
|||
|
|
digest = SHA_256(DNSKEY owner name | DNSKEY RDATA)
|
|||
|
|
|
|||
|
|
where DNSKEY RDATA is defined by [RFC4034] as:
|
|||
|
|
|
|||
|
|
DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key
|
|||
|
|
|
|||
|
|
The Key Tag field and Algorithm fields remain unchanged by this
|
|||
|
|
document and are specified in the [RFC4034] specification.
|
|||
|
|
|
|||
|
|
2.2. DS Record with SHA-256 Wire Format
|
|||
|
|
|
|||
|
|
The resulting on-the-wire format for the resulting DS record will be
|
|||
|
|
[XXX: IANA assignment should replace the 2 below]:
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Hardaker Expires August 25, 2006 [Page 3]
|
|||
|
|
|
|||
|
|
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
|
|||
|
|
|
|||
|
|
|
|||
|
|
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
|
|||
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|||
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
| Key Tag | Algorithm | DigestType=2 |
|
|||
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
/ /
|
|||
|
|
/ Digest (length for SHA-256 is 32 bytes) /
|
|||
|
|
/ /
|
|||
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
|
|||
|
|
|
|||
|
|
2.3. Example DS Record Using SHA-256
|
|||
|
|
|
|||
|
|
The following is an example DNSKEY and matching DS record. This
|
|||
|
|
DNSKEY record comes from the example DNSKEY/DS records found in
|
|||
|
|
section 5.4 of [RFC4034].
|
|||
|
|
|
|||
|
|
The DNSKEY record:
|
|||
|
|
|
|||
|
|
dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
|
|||
|
|
fwJr1AYtsmx3TGkJaNXVbfi/
|
|||
|
|
2pHm822aJ5iI9BMzNXxeYCmZ
|
|||
|
|
DRD99WYwYqUSdjMmmAphXdvx
|
|||
|
|
egXd/M5+X7OrzKBaMbCVdFLU
|
|||
|
|
Uh6DhweJBjEVv5f2wwjM9Xzc
|
|||
|
|
nOf+EPbtG9DMBmADjFDc2w/r
|
|||
|
|
ljwvFw==
|
|||
|
|
) ; key id = 60485
|
|||
|
|
|
|||
|
|
The resulting DS record covering the above DNSKEY record using a SHA-
|
|||
|
|
256 digest: [RFC Editor: please replace XXX with the assigned digest
|
|||
|
|
type (likely 2):]
|
|||
|
|
|
|||
|
|
dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C
|
|||
|
|
CEB1E3E0614B93C4F9E99B83
|
|||
|
|
83F6A1E4469DA50A )
|
|||
|
|
|
|||
|
|
|
|||
|
|
3. Implementation Requirements
|
|||
|
|
|
|||
|
|
Implementations MUST support the use of the SHA-256 algorithm in DS
|
|||
|
|
RRs. Validator implementations SHOULD ignore DS RRs containing SHA-1
|
|||
|
|
digests if DS RRs with SHA-256 digests are present in the DS RRset.
|
|||
|
|
|
|||
|
|
|
|||
|
|
4. Deployment Considerations
|
|||
|
|
|
|||
|
|
If a validator does not support the SHA-256 digest type and no other
|
|||
|
|
DS RR exists in a zone's DS RRset with a supported digest type, then
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Hardaker Expires August 25, 2006 [Page 4]
|
|||
|
|
|
|||
|
|
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
|
|||
|
|
|
|||
|
|
|
|||
|
|
the validator has no supported authentication path leading from the
|
|||
|
|
parent to the child. The resolver should treat this case as it would
|
|||
|
|
the case of an authenticated NSEC RRset proving that no DS RRset
|
|||
|
|
exists, as described in [RFC4035], section 5.2.
|
|||
|
|
|
|||
|
|
Because zone administrators can not control the deployment speed of
|
|||
|
|
support for SHA-256 in validators that may be referencing any of
|
|||
|
|
their zones, zone operators should consider deploying both SHA-1 and
|
|||
|
|
SHA-256 based DS records. This should be done for every DNSKEY for
|
|||
|
|
which DS records are being generated. Whether to make use of both
|
|||
|
|
digest types and for how long is a policy decision that extends
|
|||
|
|
beyond the scope of this document.
|
|||
|
|
|
|||
|
|
|
|||
|
|
5. IANA Considerations
|
|||
|
|
|
|||
|
|
Only one IANA action is required by this document:
|
|||
|
|
|
|||
|
|
The Digest Type to be used for supporting SHA-256 within DS records
|
|||
|
|
needs to be assigned by IANA. This document requests that the Digest
|
|||
|
|
Type value of 2 be assigned to the SHA-256 digest algorithm.
|
|||
|
|
|
|||
|
|
At the time of this writing, the current digest types assigned for
|
|||
|
|
use in DS records are as follows:
|
|||
|
|
|
|||
|
|
VALUE Digest Type Status
|
|||
|
|
0 Reserved -
|
|||
|
|
1 SHA-1 MANDATORY
|
|||
|
|
2 SHA-256 MANDATORY
|
|||
|
|
3-255 Unassigned -
|
|||
|
|
|
|||
|
|
|
|||
|
|
6. Security Considerations
|
|||
|
|
|
|||
|
|
6.1. Potential Digest Type Downgrade Attacks
|
|||
|
|
|
|||
|
|
A downgrade attack from a stronger digest type to a weaker one is
|
|||
|
|
possible if all of the following are true:
|
|||
|
|
|
|||
|
|
o A zone includes multiple DS records for a given child's DNSKEY,
|
|||
|
|
each of which use a different digest type.
|
|||
|
|
|
|||
|
|
o A validator accepts a weaker digest even if a stronger one is
|
|||
|
|
present but invalid.
|
|||
|
|
|
|||
|
|
For example, if the following conditions are all true:
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Hardaker Expires August 25, 2006 [Page 5]
|
|||
|
|
|
|||
|
|
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
|
|||
|
|
|
|||
|
|
|
|||
|
|
o Both SHA-1 and SHA-256 based digests are published in DS records
|
|||
|
|
within a parent zone for a given child zone's DNSKEY.
|
|||
|
|
|
|||
|
|
o The DS record with the SHA-1 digest matches the digest computed
|
|||
|
|
using the child zone's DNSKEY.
|
|||
|
|
|
|||
|
|
o The DS record with the SHA-256 digest fails to match the digest
|
|||
|
|
computed using the child zone's DNSKEY.
|
|||
|
|
|
|||
|
|
Then if the validator accepts the above situation as secure then this
|
|||
|
|
can be used as a downgrade attack since the stronger SHA-256 digest
|
|||
|
|
is ignored.
|
|||
|
|
|
|||
|
|
6.2. SHA-1 vs SHA-256 Considerations for DS Records
|
|||
|
|
|
|||
|
|
Users of DNSSEC are encouraged to deploy SHA-256 as soon as software
|
|||
|
|
implementations allow for it. SHA-256 is widely believed to be more
|
|||
|
|
resilient to attack than SHA-1, and confidence in SHA-1's strength is
|
|||
|
|
being eroded by recently-announced attacks. Regardless of whether or
|
|||
|
|
not the attacks on SHA-1 will affect DNSSEC, it is believed (at the
|
|||
|
|
time of this writing) that SHA-256 is the better choice for use in DS
|
|||
|
|
records.
|
|||
|
|
|
|||
|
|
At the time of this publication, the SHA-256 digest algorithm is
|
|||
|
|
considered sufficiently strong for the immediate future. It is also
|
|||
|
|
considered sufficient for use in DNSSEC DS RRs for the immediate
|
|||
|
|
future. However, future published attacks may weaken the usability
|
|||
|
|
of this algorithm within the DS RRs. It is beyond the scope of this
|
|||
|
|
document to speculate extensively on the cryptographic strength of
|
|||
|
|
the SHA-256 digest algorithm.
|
|||
|
|
|
|||
|
|
Likewise, it is also beyond the scope of this document to specify
|
|||
|
|
whether or for how long SHA-1 based DS records should be
|
|||
|
|
simultaneously published alongside SHA-256 based DS records.
|
|||
|
|
|
|||
|
|
|
|||
|
|
7. Acknowledgments
|
|||
|
|
|
|||
|
|
This document is a minor extension to the existing DNSSEC documents
|
|||
|
|
and those authors are gratefully appreciated for the hard work that
|
|||
|
|
went into the base documents.
|
|||
|
|
|
|||
|
|
The following people contributed to portions of this document in some
|
|||
|
|
fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Paul Hoffman,
|
|||
|
|
Olaf M. Kolkman, Edward Lewis, Scott Rose, Stuart E. Schechter, Sam
|
|||
|
|
Weiler.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Hardaker Expires August 25, 2006 [Page 6]
|
|||
|
|
|
|||
|
|
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
|
|||
|
|
|
|||
|
|
|
|||
|
|
8. References
|
|||
|
|
|
|||
|
|
8.1. Normative References
|
|||
|
|
|
|||
|
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|
|||
|
|
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
|||
|
|
Rose, "DNS Security Introduction and Requirements",
|
|||
|
|
RFC 4033, March 2005.
|
|||
|
|
|
|||
|
|
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
|||
|
|
Rose, "Resource Records for the DNS Security Extensions",
|
|||
|
|
RFC 4034, March 2005.
|
|||
|
|
|
|||
|
|
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
|||
|
|
Rose, "Protocol Modifications for the DNS Security
|
|||
|
|
Extensions", RFC 4035, March 2005.
|
|||
|
|
|
|||
|
|
[SHA256] National Institute of Standards and Technology, "Secure
|
|||
|
|
Hash Algorithm. NIST FIPS 180-2", August 2002.
|
|||
|
|
|
|||
|
|
8.2. Informative References
|
|||
|
|
|
|||
|
|
[SHA256CODE]
|
|||
|
|
Eastlake, D., "US Secure Hash Algorithms (SHA)",
|
|||
|
|
June 2005.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Hardaker Expires August 25, 2006 [Page 7]
|
|||
|
|
|
|||
|
|
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
|
|||
|
|
|
|||
|
|
|
|||
|
|
Author's Address
|
|||
|
|
|
|||
|
|
Wes Hardaker
|
|||
|
|
Sparta
|
|||
|
|
P.O. Box 382
|
|||
|
|
Davis, CA 95617
|
|||
|
|
US
|
|||
|
|
|
|||
|
|
Email: hardaker@tislabs.com
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Hardaker Expires August 25, 2006 [Page 8]
|
|||
|
|
|
|||
|
|
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
|
|||
|
|
|
|||
|
|
|
|||
|
|
Intellectual Property Statement
|
|||
|
|
|
|||
|
|
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.
|
|||
|
|
|
|||
|
|
|
|||
|
|
Disclaimer of Validity
|
|||
|
|
|
|||
|
|
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.
|
|||
|
|
|
|||
|
|
|
|||
|
|
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.
|
|||
|
|
|
|||
|
|
|
|||
|
|
Acknowledgment
|
|||
|
|
|
|||
|
|
Funding for the RFC Editor function is currently provided by the
|
|||
|
|
Internet Society.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Hardaker Expires August 25, 2006 [Page 9]
|
|||
|
|
|