draft-ietf-dnsext-ds-sha256-05.txt | rfc4509.txt | |||
---|---|---|---|---|
Network Working Group W. Hardaker | Network Working Group W. Hardaker | |||
Internet-Draft Sparta | Request for Comments: 4509 Sparta | |||
Expires: August 25, 2006 February 21, 2006 | Category: Standards Track May 2006 | |||
Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) | 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 | Status of This Memo | |||
http://www.ietf.org/shadow.html. | ||||
This Internet-Draft will expire on August 25, 2006. | This document specifies an Internet standards track protocol for the | |||
Internet community, and requests discussion and suggestions for | ||||
improvements. Please refer to the current edition of the "Internet | ||||
Official Protocol Standards" (STD 1) for the standardization state | ||||
and status of this protocol. Distribution of this memo is unlimited. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2006). | Copyright (C) The Internet Society (2006). | |||
Abstract | Abstract | |||
This document specifies how to use the SHA-256 digest type in DNS | This document specifies how to use the SHA-256 digest type in DNS | |||
Delegation Signer (DS) Resource Records (RRs). DS records, when | Delegation Signer (DS) Resource Records (RRs). DS records, when | |||
stored in a parent zone, point to key signing DNSKEY key(s) in a | stored in a parent zone, point to DNSKEYs in a child zone. | |||
child zone. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction ....................................................2 | |||
2. Implementing the SHA-256 algorithm for DS record support . . . 3 | 2. Implementing the SHA-256 Algorithm for DS Record Support ........2 | |||
2.1. DS record field values . . . . . . . . . . . . . . . . . . 3 | 2.1. DS Record Field Values .....................................2 | |||
2.2. DS Record with SHA-256 Wire Format . . . . . . . . . . . . 3 | 2.2. DS Record with SHA-256 Wire Format .........................3 | |||
2.3. Example DS Record Using SHA-256 . . . . . . . . . . . . . . 4 | 2.3. Example DS Record Using SHA-256 ............................3 | |||
3. Implementation Requirements . . . . . . . . . . . . . . . . . . 4 | 3. Implementation Requirements .....................................3 | |||
4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 4 | 4. Deployment Considerations .......................................4 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 | 5. IANA Considerations .............................................4 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 | 6. Security Considerations .........................................4 | |||
6.1. Potential Digest Type Downgrade Attacks . . . . . . . . . . 5 | 6.1. Potential Digest Type Downgrade Attacks ....................4 | |||
6.2. SHA-1 vs SHA-256 Considerations for DS Records . . . . . . 6 | 6.2. SHA-1 vs SHA-256 Considerations for DS Records .............5 | |||
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 | 7. Acknowledgements ................................................5 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 8. References ......................................................6 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 | 8.1. Normative References .......................................6 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . . 7 | 8.2. Informative References .....................................6 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 | ||||
Intellectual Property and Copyright Statements . . . . . . . . . . 9 | ||||
1. Introduction | 1. Introduction | |||
The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent | The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent | |||
zones to distribute a cryptographic digest of a child's Key Signing | zones to distribute a cryptographic digest of one key in a child's | |||
Key (KSK) DNSKEY RR. The DS RRset is signed by at least one of the | DNSKEY RRset. The DS RRset is signed by at least one of the parent | |||
parent zone's private zone data signing keys for each algorithm in | zone's private zone data signing keys for each algorithm in use by | |||
use by the parent. Each signature is published in an RRSIG resource | the parent. Each signature is published in an RRSIG resource record, | |||
record, owned by the same domain as the DS RRset and with a type | owned by the same domain as the DS RRset, with a type covered of DS. | |||
covered of DS. | ||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | In this document, the key words "MUST", "MUST NOT", "REQUIRED", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", | |||
document are to be interpreted as described in [RFC2119]. | and "OPTIONAL" are to be interpreted as described in [RFC2119]. | |||
2. Implementing the SHA-256 algorithm for DS record support | 2. Implementing the SHA-256 Algorithm for DS Record Support | |||
This document specifies that the digest type code [XXX: To be | This document specifies that the digest type code 2 has been assigned | |||
assigned by IANA; likely 2] is to be assigned to SHA-256 [SHA256] | to SHA-256 [SHA256] [SHA256CODE] for use within DS records. The | |||
[SHA256CODE] for use within DS records. The results of the digest | results of the digest algorithm MUST NOT be truncated, and the entire | |||
algorithm MUST NOT be truncated and the entire 32 byte digest result | 32 byte digest result is to be published in the DS record. | |||
is to be published in the DS record. | ||||
2.1. DS record field values | 2.1. DS Record Field Values | |||
Using the SHA-256 digest algorithm within a DS record will make use | Using the SHA-256 digest algorithm within a DS record will make use | |||
of the following DS-record fields: | of the following DS-record fields: | |||
Digest type: [XXX: To be assigned by IANA; likely 2] | Digest type: 2 | |||
Digest: A SHA-256 bit digest value calculated by using the following | Digest: A SHA-256 bit digest value calculated by using the following | |||
formula ("|" denotes concatenation). The resulting value is not | formula ("|" denotes concatenation). The resulting value is not | |||
truncated and the entire 32 byte result is to used in the | truncated, and the entire 32 byte result is to be used in the | |||
resulting DS record and related calculations. | resulting DS record and related calculations. | |||
digest = SHA_256(DNSKEY owner name | DNSKEY RDATA) | digest = SHA_256(DNSKEY owner name | DNSKEY RDATA) | |||
where DNSKEY RDATA is defined by [RFC4034] as: | where DNSKEY RDATA is defined by [RFC4034] as: | |||
DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key | DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key | |||
The Key Tag field and Algorithm fields remain unchanged by this | The Key Tag field and Algorithm fields remain unchanged by this | |||
document and are specified in the [RFC4034] specification. | document and are specified in the [RFC4034] specification. | |||
2.2. DS Record with SHA-256 Wire Format | 2.2. DS Record with SHA-256 Wire Format | |||
The resulting on-the-wire format for the resulting DS record will be | The resulting on-the-wire format for the resulting DS record will be | |||
[XXX: IANA assignment should replace the 2 below]: | as follows: | |||
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | 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 | 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 | | | Key Tag | Algorithm | DigestType=2 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
/ / | / / | |||
/ Digest (length for SHA-256 is 32 bytes) / | / Digest (length for SHA-256 is 32 bytes) / | |||
/ / | / / | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | |||
skipping to change at page 4, line 33 | skipping to change at page 3, line 38 | |||
dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz | dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz | |||
fwJr1AYtsmx3TGkJaNXVbfi/ | fwJr1AYtsmx3TGkJaNXVbfi/ | |||
2pHm822aJ5iI9BMzNXxeYCmZ | 2pHm822aJ5iI9BMzNXxeYCmZ | |||
DRD99WYwYqUSdjMmmAphXdvx | DRD99WYwYqUSdjMmmAphXdvx | |||
egXd/M5+X7OrzKBaMbCVdFLU | egXd/M5+X7OrzKBaMbCVdFLU | |||
Uh6DhweJBjEVv5f2wwjM9Xzc | Uh6DhweJBjEVv5f2wwjM9Xzc | |||
nOf+EPbtG9DMBmADjFDc2w/r | nOf+EPbtG9DMBmADjFDc2w/r | |||
ljwvFw== | ljwvFw== | |||
) ; key id = 60485 | ) ; key id = 60485 | |||
The resulting DS record covering the above DNSKEY record using a SHA- | The resulting DS record covering the above DNSKEY record using a | |||
256 digest: [RFC Editor: please replace XXX with the assigned digest | SHA-256 digest: | |||
type (likely 2):] | ||||
dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C | dskey.example.com. 86400 IN DS 60485 5 2 ( D4B7D520E7BB5F0F67674A0C | |||
CEB1E3E0614B93C4F9E99B83 | CEB1E3E0614B93C4F9E99B83 | |||
83F6A1E4469DA50A ) | 83F6A1E4469DA50A ) | |||
3. Implementation Requirements | 3. Implementation Requirements | |||
Implementations MUST support the use of the SHA-256 algorithm in DS | Implementations MUST support the use of the SHA-256 algorithm in DS | |||
RRs. Validator implementations SHOULD ignore DS RRs containing SHA-1 | RRs. Validator implementations SHOULD ignore DS RRs containing SHA-1 | |||
digests if DS RRs with SHA-256 digests are present in the DS RRset. | digests if DS RRs with SHA-256 digests are present in the DS RRset. | |||
4. Deployment Considerations | 4. Deployment Considerations | |||
If a validator does not support the SHA-256 digest type and no other | 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 | DS RR exists in a zone's DS RRset with a supported digest type, then | |||
the validator has no supported authentication path leading from the | the validator has no supported authentication path leading from the | |||
parent to the child. The resolver should treat this case as it would | 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 | the case of an authenticated NSEC RRset proving that no DS RRset | |||
exists, as described in [RFC4035], section 5.2. | exists, as described in [RFC4035], Section 5.2. | |||
Because zone administrators can not control the deployment speed of | Because zone administrators can not control the deployment speed of | |||
support for SHA-256 in validators that may be referencing any of | support for SHA-256 in validators that may be referencing any of | |||
their zones, zone operators should consider deploying both SHA-1 and | their zones, zone operators should consider deploying both SHA-1 and | |||
SHA-256 based DS records. This should be done for every DNSKEY for | 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 | which DS records are being generated. Whether to make use of both | |||
digest types and for how long is a policy decision that extends | digest types and for how long is a policy decision that extends | |||
beyond the scope of this document. | beyond the scope of this document. | |||
5. IANA Considerations | 5. IANA Considerations | |||
Only one IANA action is required by this document: | Only one IANA action is required by this document: | |||
The Digest Type to be used for supporting SHA-256 within DS records | 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 | has been assigned by IANA. | |||
Type value of 2 be assigned to the SHA-256 digest algorithm. | ||||
At the time of this writing, the current digest types assigned for | At the time of this writing, the current digest types assigned for | |||
use in DS records are as follows: | use in DS records are as follows: | |||
VALUE Digest Type Status | VALUE Digest Type Status | |||
0 Reserved - | 0 Reserved - | |||
1 SHA-1 MANDATORY | 1 SHA-1 MANDATORY | |||
2 SHA-256 MANDATORY | 2 SHA-256 MANDATORY | |||
3-255 Unassigned - | 3-255 Unassigned - | |||
6. Security Considerations | 6. Security Considerations | |||
6.1. Potential Digest Type Downgrade Attacks | 6.1. Potential Digest Type Downgrade Attacks | |||
A downgrade attack from a stronger digest type to a weaker one is | A downgrade attack from a stronger digest type to a weaker one is | |||
possible if all of the following are true: | possible if all of the following are true: | |||
o A zone includes multiple DS records for a given child's DNSKEY, | o A zone includes multiple DS records for a given child's DNSKEY, | |||
each of which use a different digest type. | each of which uses a different digest type. | |||
o A validator accepts a weaker digest even if a stronger one is | o A validator accepts a weaker digest even if a stronger one is | |||
present but invalid. | present but invalid. | |||
For example, if the following conditions are all true: | For example, if the following conditions are all true: | |||
o Both SHA-1 and SHA-256 based digests are published in DS records | 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. | within a parent zone for a given child zone's DNSKEY. | |||
o The DS record with the SHA-1 digest matches the digest computed | o The DS record with the SHA-1 digest matches the digest computed | |||
using the child zone's DNSKEY. | using the child zone's DNSKEY. | |||
o The DS record with the SHA-256 digest fails to match the digest | o The DS record with the SHA-256 digest fails to match the digest | |||
computed using the child zone's DNSKEY. | computed using the child zone's DNSKEY. | |||
Then if the validator accepts the above situation as secure then this | Then, if the validator accepts the above situation as secure, then | |||
can be used as a downgrade attack since the stronger SHA-256 digest | this can be used as a downgrade attack since the stronger SHA-256 | |||
is ignored. | digest is ignored. | |||
6.2. SHA-1 vs SHA-256 Considerations for DS Records | 6.2. SHA-1 vs. SHA-256 Considerations for DS Records | |||
Users of DNSSEC are encouraged to deploy SHA-256 as soon as software | 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 | 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 | resilient to attack than SHA-1, and confidence in SHA-1's strength is | |||
being eroded by recently-announced attacks. Regardless of whether or | being eroded by recently announced attacks. Regardless of whether | |||
not the attacks on SHA-1 will affect DNSSEC, it is believed (at the | the attacks on SHA-1 will affect DNSSEC, it is believed (at the time | |||
time of this writing) that SHA-256 is the better choice for use in DS | of this writing) that SHA-256 is the better choice for use in DS | |||
records. | records. | |||
At the time of this publication, the SHA-256 digest algorithm is | At the time of this publication, the SHA-256 digest algorithm is | |||
considered sufficiently strong for the immediate future. It is also | considered sufficiently strong for the immediate future. It is also | |||
considered sufficient for use in DNSSEC DS RRs for the immediate | considered sufficient for use in DNSSEC DS RRs for the immediate | |||
future. However, future published attacks may weaken the usability | future. However, future published attacks may weaken the usability | |||
of this algorithm within the DS RRs. It is beyond the scope of this | of this algorithm within the DS RRs. It is beyond the scope of this | |||
document to speculate extensively on the cryptographic strength of | document to speculate extensively on the cryptographic strength of | |||
the SHA-256 digest algorithm. | the SHA-256 digest algorithm. | |||
Likewise, it is also beyond the scope of this document to specify | Likewise, it is also beyond the scope of this document to specify | |||
whether or for how long SHA-1 based DS records should be | whether or for how long SHA-1 based DS records should be | |||
simultaneously published alongside SHA-256 based DS records. | simultaneously published alongside SHA-256 based DS records. | |||
7. Acknowledgments | 7. Acknowledgements | |||
This document is a minor extension to the existing DNSSEC documents | This document is a minor extension to the existing DNSSEC documents | |||
and those authors are gratefully appreciated for the hard work that | and those authors are gratefully appreciated for the hard work that | |||
went into the base documents. | went into the base documents. | |||
The following people contributed to portions of this document in some | The following people contributed to portions of this document in some | |||
fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Paul Hoffman, | fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Paul Hoffman, | |||
Olaf M. Kolkman, Edward Lewis, Scott Rose, Stuart E. Schechter, Sam | Olaf M. Kolkman, Edward Lewis, Scott Rose, Stuart E. Schechter, Sam | |||
Weiler. | Weiler. | |||
8. References | 8. References | |||
8.1. Normative References | 8.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. | [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. | |||
Rose, "DNS Security Introduction and Requirements", | Rose, "DNS Security Introduction and Requirements", RFC | |||
RFC 4033, March 2005. | 4033, March 2005. | |||
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. | [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. | |||
Rose, "Resource Records for the DNS Security Extensions", | Rose, "Resource Records for the DNS Security | |||
RFC 4034, March 2005. | Extensions", RFC 4034, March 2005. | |||
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. | [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. | |||
Rose, "Protocol Modifications for the DNS Security | Rose, "Protocol Modifications for the DNS Security | |||
Extensions", RFC 4035, March 2005. | Extensions", RFC 4035, March 2005. | |||
[SHA256] National Institute of Standards and Technology, "Secure | [SHA256] National Institute of Standards and Technology, "Secure | |||
Hash Algorithm. NIST FIPS 180-2", August 2002. | Hash Algorithm. NIST FIPS 180-2", August 2002. | |||
8.2. Informative References | 8.2. Informative References | |||
[SHA256CODE] | [SHA256CODE] Eastlake, D., "US Secure Hash Algorithms (SHA)", Work in | |||
Eastlake, D., "US Secure Hash Algorithms (SHA)", | Progress. | |||
June 2005. | ||||
Author's Address | Author's Address | |||
Wes Hardaker | Wes Hardaker | |||
Sparta | Sparta | |||
P.O. Box 382 | P.O. Box 382 | |||
Davis, CA 95617 | Davis, CA 95617 | |||
US | USA | |||
Email: hardaker@tislabs.com | EMail: hardaker@tislabs.com | |||
Intellectual Property Statement | 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 | The IETF takes no position regarding the validity or scope of any | |||
Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
this document or the extent to which any license under such rights | 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 | might or might not be available; nor does it represent that it has | |||
made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |||
on the procedures with respect to rights in RFC documents can be | on the procedures with respect to rights in RFC documents can be | |||
found in BCP 78 and BCP 79. | found in BCP 78 and BCP 79. | |||
skipping to change at page 9, line 29 | skipping to change at page 7, line 45 | |||
such proprietary rights by implementers or users of this | such proprietary rights by implementers or users of this | |||
specification can be obtained from the IETF on-line IPR repository at | specification can be obtained from the IETF on-line IPR repository at | |||
http://www.ietf.org/ipr. | http://www.ietf.org/ipr. | |||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
this standard. Please address the information to the IETF at | this standard. Please address the information to the IETF at | |||
ietf-ipr@ietf.org. | ietf-ipr@ietf.org. | |||
Disclaimer of Validity | Acknowledgement | |||
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 | Funding for the RFC Editor function is provided by the IETF | |||
Internet Society. | Administrative Support Activity (IASA). | |||
End of changes. 31 change blocks. | ||||
107 lines changed or deleted | 81 lines changed or added | |||
This html diff was produced by rfcdiff 1.31. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |