draft-ietf-dnsind-sig-zero-00.txt   draft-ietf-dnsind-sig-zero-01.txt 
INTERNET-DRAFT Donald E. Eastlake 3rd INTERNET-DRAFT Donald E. Eastlake 3rd
UPDATES RFC 2535 IBM UPDATES RFC 2535 IBM
Expires: April 2000 October 1999 Expires: June 2000 December 1999
draft-ietf-dnsind-sig-zero-00.txt draft-ietf-dnsind-sig-zero-01.txt
DNS Request and Transaction Signatures ( SIG(0)s ) DNS Request and Transaction Signatures ( SIG(0)s )
--- ------- --- ----------- ---------- - ------- - --- ------- --- ----------- ---------- - ------- -
Status of This Document Status of This Document
This draft, file name draft-ietf-dnsind-sig-zero-00.txt, is intended This draft, file name draft-ietf-dnsind-sig-zero-01.txt, is intended
to become a Proposed Standard RFC updating Proposed Standard [RFC to become a Proposed Standard RFC updating Proposed Standard [RFC
2535]. Distribution of this document is unlimited. Comments should 2535]. Distribution of this document is unlimited. Comments should
be sent to the DNS Working Group mailing list be sent to the DNS Working Group mailing list
<namedroppers@internic.net> or to the author. <namedroppers@internic.net> or to the author.
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at page 2, line 5 skipping to change at page 2, line 5
Extensions to the Domain Name System (DNS) are described in [RFC Extensions to the Domain Name System (DNS) are described in [RFC
2535] that can provide data origin and transaction integrity and 2535] that can provide data origin and transaction integrity and
authentication to security aware resolvers and applications through authentication to security aware resolvers and applications through
the use of cryptographic digital signatures. the use of cryptographic digital signatures.
Implementation experience has indicated the need for minor but non- Implementation experience has indicated the need for minor but non-
interoperable changes in Request and Transaction signature resource interoperable changes in Request and Transaction signature resource
records ( SIG(0)s ). These changes are documented herein. records ( SIG(0)s ). These changes are documented herein.
*
Acknowledgments Acknowledgments
The significant contributions and suggestions of the following The significant contributions and suggestions of the following
persons (in alphabetic order) to this draft are gratefully persons (in alphabetic order) to this draft are gratefully
acknowledged: acknowledged:
Olafur Gudmundsson Olafur Gudmundsson
Brian Wellington Brian Wellington
Table of Contents Table of Contents
[Table of Contents gets moved here from the end] Status of This Document....................................1
Abstract...................................................1
* Acknowledgments............................................2
Table of Contents..........................................2
1. Introduction............................................3
2. SIG(0) Design Rationale.................................3
2.1 Transaction Authentication.............................3
2.2 Query Authentication...................................4
2.3 Keying.................................................4
2.4 Differences Between TSIG and SIG(0)....................4
3. The SIG(0) Resource Record..............................6
3.1 Calculating Request and Transaction SIGs...............6
3.2 Processing Responses and SIG(0) RRs....................7
3.3 SIG(0) Lifetime and Expiration.........................8
4. Security Considerations.................................9
5. IANA Considerations.....................................9
References.................................................9
Author's Address..........................................10
Expiration and File Name..................................10
Appendix: SIG(0) Changes from RFC 2535....................10
1. Introduction 1. Introduction
This document makes minor but non-interoperable changes to part of This document makes minor but non-interoperable changes to part of
[RFC 2535], familiarity with which is assumed, and includes [RFC 2535], familiarity with which is assumed, and includes
additional explanatory text. These changes concern SIG Resource additional explanatory text. These changes concern SIG Resource
Records that are used to sign DNS requests and transactions / Records (RRs) that are used to sign DNS requests and transactions /
responses. Such a resource record, because it has a type covered responses. Such a resource record, because it has a type covered
field of zero, is frequently called a SIG(0). The changes are based field of zero, is frequently called a SIG(0). The changes are based
on implementation and attempted implementation experience with TSIG on implementation and attempted implementation experience with TSIG
[draft-ietf-dnsind-tsig-*.txt] and the [RFC 2535] specification for [draft-ietf-dnsind-tsig-*.txt] and the [RFC 2535] specification for
SIG(0). SIG(0).
No changes are made herein related to the KEY or NXT RRs or to the Sections of [RFC 2535] updated are all of 4.1.8.1 and parts of 4.2
processing involved with data origin and denial authentication for and 4.3. No changes are made herein related to the KEY or NXT RRs or
DNS data. to the processing involved with data origin and denial authentication
for DNS data.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119]. document are to be interpreted as described in [RFC 2119].
* 2. SIG(0) Design Rationale
2. SIG(0) Design Rational
The authenticated data origin and data existence denial services of The authenticated data origin and data existence denial services of
secure DNS protect only data resource records (RRs) or secure DNS protect only data resource records (RRs) or
authenticatably deny their nonexistence. These services provide no authenticatably deny their nonexistence. These services provide no
protection for DNS requests, no protection for message headers on protection for DNS requests, no protection for message headers on
requests or responses, and no protection of the overall integrity of requests or responses, and no protection of the overall integrity of
a response. a response.
If header bits are falsely set by a bad server, there is little that If header bits are falsely set by a bad server, there is little that
can be done. However, it is possible to add transaction can be done. However, it is possible to add transaction and query
authentication. Such authentication means that a requester can be authentication to be sure that queries and responses and not tampered
sure it is at least getting messages from the server it thinks it with in transit.
queried and that the response is from the request it sent (i.e., that
these messages have not been diddled in transit). This is 2.1 Transaction Authentication
accomplished by optionally adding either a TSIG RR [draft-ietf-
dnsind-tsig-*.txt] or, as described herein, a SIG resource record at Transaction authentication means that a requester can be sure it is
the end of the response which digitally signs both the server's at least getting the messages from the server it queried and that the
response and the corresponding resolver query. response is from the request it sent (i.e., that these messages have
not been diddled in transit). This is accomplished by optionally
adding either a TSIG RR [draft-ietf-dnsind-tsig-*.txt] or, as
described herein, a SIG(0) resource record at the end of the response
which digitally signs the concatenation of the server's response and
the corresponding resolver query.
2.2 Query Authentication
Requests can also be authenticated by including a TSIG or, as Requests can also be authenticated by including a TSIG or, as
described herein, a special SIG RR at the end of the request. described herein, a special SIG(0) RR at the end of the request.
Authenticating requests serves no function in older DNS servers. Authenticating requests serves no function in DNS servers the predate
Requests with a non-empty additional information section produce the specification of dynamic update. Requests with a non-empty
error returns or may even be ignored by a few older DNS servers. additional information section produce error returns or may even be
However, this syntax for signing requests is defined for ignored by a few such older DNS servers. However, this syntax for
authenticating dynamic update requests [RFC 2136], TKEY [draft-ietf- signing requests is defined for authenticating dynamic update
dnsind-tkey-*.txt], or future requests requiring authentication. requests [RFC 2136], TKEY requests [draft-ietf-dnsind-tkey-*.txt], or
future requests requiring authentication.
2.3 Keying
The private keys used in transaction security belong to the host The private keys used in transaction security belong to the host
composing the DNS message, not to the zone involved. Request composing the DNS response message, not to the zone involved.
authentication may also involve the private key of the host or other Request authentication may also involve the private key of the host
entity composing the request or other private keys depending on the or other entity composing the request or of a zone to be affected by
request authority it is sought to establish. The corresponding public the request or other private keys depending on the request authority
key(s) are normally stored in and retrieved from the DNS for it is sought to establish. The corresponding public key(s) are
verification. normally stored in and retrieved from the DNS for verification as KEY
RRs with a protocol byte of 3 (DNSSEC) or 255 (ANY).
Because requests and replies are highly variable, message Because requests and replies are highly variable, message
authentication SIGs can not be pre-calculated. Thus it will be authentication SIGs can not be pre-calculated. Thus it will be
necessary to keep the private key on-line, for example in software or necessary to keep the private key on-line, for example in software or
in a directly connected piece of hardware. in a directly connected piece of hardware.
2.1 Differences Between TSIG and SIG(0) 2.4 Differences Between TSIG and SIG(0)
There are significant differences between TSIG and SIG(0). There are significant differences between TSIG and SIG(0).
Because TSIG involves secret keys installed at both the requester and Because TSIG involves secret keys installed at both the requester and
server the presence of such a key implies that the other party server the presence of such a key implies that the other party
*
understands TSIG and likely has the same key installed. Furthermore, understands TSIG and likely has the same key installed. Furthermore,
TSIG uses keyed hash authentication codes which are relatively TSIG uses keyed hash authentication codes which are relatively
inexpensive to compute. Thus it is common to sign requests with TSIG inexpensive to compute. Thus it is common to authenticate requests
and responses are signed with TSIG if the corresponding request is with TSIG and responses are authenticated with TSIG if the
signed. corresponding request is authenticated.
SIG(0) on the other hand, uses KEY RRs that are stored in the DNS SIG(0) on the other hand, uses public key authentication, where the
under the host name. Thus, existence of such a KEY RR does not public keys are stored in DNS as KEY RRs. Thus, existence of such a
necessarily imply implementation of SIG(0). In addition, SIG(0) KEY RR does not necessarily imply implementation of SIG(0). In
involves relatively expensive public key cryptographic operations addition, SIG(0) involves relatively expensive public key
that should be minimized and the verification of a SIG(0) involves cryptographic operations that should be minimized and the
obtaining and verifying the corresponding KEY which can be an verification of a SIG(0) involves obtaining and verifying the
expensive and lengthy operation. Indeed, a policy of using SIG(0) on corresponding KEY which can be an expensive and lengthy operation.
all requests and verifying it before responding would, for some Indeed, a policy of using SIG(0) on all requests and verifying it
configurations, lead to a deadly embrace with the attempt to obtain before responding would, for some configurations, lead to a deadly
and verify the KEY needed to authenticate the request SIG(0) embrace with the attempt to obtain and verify the KEY needed to
resulting in additional requests accompanied by a SIG(0) leading to authenticate the request SIG(0) resulting in additional requests
further requests accompanied by a SIG(0), etc. Furthermore, omitting accompanied by a SIG(0) leading to further requests accompanied by a
SIG(0)s when not required on requests halves the number of public key SIG(0), etc. Furthermore, omitting SIG(0)s when not required on
operations required by the transaction. requests halves the number of public key operations required by the
transaction.
For these reasons, SIG(0)s MUST only be used on requests when For these reasons, SIG(0)s SHOULD only be used on requests when
necessary to authentication that the requester has some required necessary to authenticate that the requester has some required
privilege or identity. SIG(0)s on replies are defined in such a way privilege or identity. SIG(0)s on replies are defined in such a way
as to not require a SIG(0) on the corresponding request and still as to not require a SIG(0) on the corresponding request and still
provide transaction protection. Some replies, such as those provide transaction protection. Some replies, such as those
involving TKEY [draft-ietf-dnsind-tkey-*.txt], MUST be signed with involving TKEY [draft-ietf-dnsind-tkey-*.txt], MUST be authenticated
TSIG or SIG(0). For other replies, whether they are signed by the with TSIG or SIG(0). For other replies, whether they are
server or required to be signed by the requester SHOULD be a local authenticated by the server or required to be authenticated by the
configuration option. requester SHOULD be a local configuration option.
*
3. The SIG(0) Resource Record 3. The SIG(0) Resource Record
The structure of and type number of SIG resource records (RRs) is The structure of and type number of SIG resource records (RRs) is
given in [RFC 2535] Section 4.1. However all of Section 4.1.8.1 and given in [RFC 2535] Section 4.1. However all of Section 4.1.8.1 and
the parts of Sections 4.2 and 4.3 related to SIG(0) should be the parts of Sections 4.2 and 4.3 related to SIG(0) should be
considered replaced by the material below. Any conflict between [RFC considered replaced by the material below. Any conflict between [RFC
2535] and this document concerning SIG(0) RRs should be resolved in 2535] and this document concerning SIG(0) RRs should be resolved in
favor of this document. favor of this document.
For all SIG(0)s, the signer field MUST be a name of the originating For all transaction SIG(0)s, the signer field MUST be the name of the
server host. (The inverse IP address mapping name MAY be used if the originating server host and there MUST be a KEY RR at that name with
relevant KEY is stored there.) However, the owner name, class, TTL, the public key corresponding to the private key used to calculate the
and original TTL, are meaningless. The class and TTL fields SHOULD signature. (The inverse IP address mapping name MAY be used if the
be zero. To conserve space, the owner name SHOULD be root (a single relevant KEY is stored there.)
zero octet). When SIG(0) authentication on a response is desired,
that SIG RR must be considered the highest priority for inclusion in For all SIG(0) RRs, the owner name, class, TTL, and original TTL, are
the response. meaningless. The TTL fields SHOULD be zero and the CLASS filed
SHOULD be ANY. To conserve space, the owner name SHOULD be root (a
single zero octet). When SIG(0) authentication on a response is
desired, that SIG RR must be considered the highest priority of any
additional information for inclusion in the response. If the SIG(0)
RR cannot be added without causing the message to be truncated, the
server MUST alter the response so that a SIG(0) can be included.
This response consists of only the question and a SIG(0) record, and
has the TC bit set and RCODE 0 (NOERROR). The client SHOULD at this
point retry the request using TCP.
3.1 Calculating Request and Transaction SIGs 3.1 Calculating Request and Transaction SIGs
A DNS request may be optionally signed by including one or more SIGs A DNS request may be optionally signed by including one or more
at the end of the query additional information section. Such SIGs SIG(0)s at the end of the query additional information section. Such
are identified by having a "type covered" field of zero. They sign SIGs are identified by having a "type covered" field of zero. They
the preceding DNS request message including DNS header but not sign the preceding DNS request message including DNS header but not
including the UDP/IP header or any request SIG(0)s or TSIGs [draft- including the UDP/IP header or any request SIG(0)s at the end and
ietf-dnsind-tsig-*.txt] at the end and before the request RR counts before the request RR counts have been adjusted for the inclusions of
have been adjusted for the inclusions of any request SIG(0)s or any request SIG(0)s.
TSIGs.
Note: requests and response can either have a TSIG or one or more
SIG(0)s but not both a TSIG and a SIG(0).
They are calculated by using a "data" (see [RFC 2535], Section 4.1.8) They are calculated by using a "data" (see [RFC 2535], Section 4.1.8)
of (1) the SIG's RDATA section omitting the signature subfield of (1) the SIG's RDATA section omitting the signature subfield
itself, (2) the entire DNS query messages, including DNS header, but itself, (2) the entire DNS query messages, including DNS header, but
not the UDP/IP header or any SIG(0) or TSIG and before the reply RR not the UDP/IP header or any SIG(0) and before the reply RR counts
counts have been adjusted for the inclusion of any SIG(0) or TSIG. have been adjusted for the inclusion of any SIG(0). That is
That is
data = RDATA | request (- SIG(0)s & TSIGs)
data = RDATA | request - SIG(0)s
where "|" is concatenation and RDATA is the RDATA of the SIG(0) being where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
calculated less the signature itself. calculated less the signature itself.
Similarly, a SIG(0) can be used to secure a response and the request Similarly, a SIG(0) can be used to secure a response and the request
that produced it. Such transaction signatures are calculated by that produced it. Such transaction signatures are calculated by
using a "data" of (1) the SIG's RDATA section omitting the signature using a "data" of (1) the SIG's RDATA section omitting the signature
itself, (2) the entire DNS query message that produced this response, itself, (2) the entire DNS query message that produced this response,
including the query's DNS header and any SIG(0)s or TSIGs but not its including the query's DNS header and any SIG(0)s but not its UDP/IP
UDP/IP header, and (3) the entire DNS response message, including DNS header, and (3) the entire DNS response message, including DNS header
header but not the UDP/IP header or any SIG(0) or TSIGs and before but not the UDP/IP header or any SIG(0) and before the response RR
counts have been adjusted for the inclusion of any SIG(0).
*
the response RR counts have been adjusted for the inclusion of any
SIG(0) or TSIG.
That is That is
data = RDATA | full query | response (- SIG(0)s & TSIGs) data = RDATA | full query | response - SIG(0)s
where "|" is concatenation and RDATA is the RDATA of the SIG(0) being where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
calculated less the signature itself. calculated less the signature itself.
Verification of a response SIG(0) (which is signed by the server host Verification of a response SIG(0) (which is signed by the server host
key, not the zone key) by the requesting resolver shows that the key, not the zone key) by the requesting resolver shows that the
query and response were not tampered with in transit, that the query and response were not tampered with in transit, that the
response corresponds to the intended query, and that the response response corresponds to the intended query, and that the response
comes from the queried server. comes from the queried server.
In the case of a DNS message via TCP, a SIG(0) on the first data In the case of a DNS message via TCP, a SIG(0) on the first data
packet is calculated with "data" as above and for each subsequent packet is calculated with "data" as above and for each subsequent
packet, it is calculated as follows: packet, it is calculated as follows:
data = RDATA | DNS payload (- SIG(0)s & TSIGs) | previous packet data = RDATA | DNS payload - SIG(0)s | previous packet
where RDATA is as above and previous packet is the previous DNS where "|" is concatenations, RDATA is as above, and previous packet
payload including DNS header and any SIG(0)s and TSIGs but not the is the previous DNS payload including DNS header and any SIG(0)s but
TCP/IP header. Support of TCP SIG(0) for is OPTIONAL. As an not the TCP/IP header. Support of SIG(0) for TCP is OPTIONAL. As an
alternative, TSIG may be used after, if necessary, setting up a key alternative, TSIG may be used after, if necessary, setting up a key
with TKEY [draft-ietf-dnsind-tkey-*.txt]. with TKEY [draft-ietf-dnsind-tkey-*.txt].
Except where needed to authenticate an update, TKEY, or similar Except where needed to authenticate an update, TKEY, or similar
privileged request, servers are not required to check request SIGs. privileged request, servers are not required to check request SIGs.
3.2 Processing Responses and SIG(0) RRs 3.2 Processing Responses and SIG(0) RRs
If a SIG RR is at the end of the additional information section of a If a SIG RR is at the end of the additional information section of a
response and has a type covered of zero, it is a transaction response and has a type covered of zero, it is a transaction
signature covering the response and the query that produced the signature covering the response and the query that produced the
response. For all TKEY responses, it MUST be checked and the message response. For TKEY responses, it MUST be checked and the message
rejected if the checks fail. For all other responses, it MAY be rejected if the checks fail. For all other responses, it MAY be
optionally checked and the message rejected if the checks fail. checked and the message rejected if the checks fail.
If response SIG(0) checks succeed, such a transaction authentication If a response SIG(0) checks succeed, such a transaction
SIG does NOT directly authenticate any data-RRs in the message but authentication SIG does NOT directly authenticate the validity any
does authenticate TKEY and other meta-RRs. (Only a proper SIG RR data-RRs in the message. However, it authenticates that they were
signed by the zone or a key tracing its authority to the zone or to sent by the queried server and have not been diddled. (Only a proper
static resolver configuration can directly authenticate data-RRs, SIG(0) RR signed by the zone or a key tracing its authority to the
depending on resolver policy.) If a resolver or server does not zone or to static resolver configuration can directly authenticate
implement transaction and/or request SIGs, it MUST ignore them data-RRs, depending on resolver policy.) If a resolver or server does
not implement transaction and/or request SIGs, it MUST ignore them
without error where they are optional and treat them as failing where without error where they are optional and treat them as failing where
*
they are required. they are required.
3.3 SIG(0) Lifetime and Expiration 3.3 SIG(0) Lifetime and Expiration
The inception and expiration times in SIG(0)s are for the purpose of The inception and expiration times in SIG(0)s are for the purpose of
resisting replay attacks. They should be set to form a time bracket resisting replay attacks. They should be set to form a time bracket
such that messages outside that bracket can be ignored. In IP such that messages outside that bracket can be ignored. In IP
networks, this time bracket should not normally extend further than 5 networks, this time bracket should not normally extend further than 5
minutes into the past and 5 minutes into the future. minutes into the past and 5 minutes into the future.
*
4. Security Considerations 4. Security Considerations
No additional considerations beyond those in [RFC 2535]. The No additional considerations beyond those in [RFC 2535].
inclusion of the SIG(0) inception and expiration time under the
The inclusion of the SIG(0) inception and expiration time under the
signature improves resistance to replay attacks. signature improves resistance to replay attacks.
5. IANA Considerations 5. IANA Considerations
No new fields are created or field values assigned by the document. No new fields are created or field values assigned by the document.
References References
[RFC 1982] - Robert Elz, Randy Bush, "Serial Number Arithmetic", [RFC 1982] - Robert Elz, Randy Bush, "Serial Number Arithmetic",
09/03/1996. 09/03/1996.
skipping to change at page 10, line 5 skipping to change at page 10, line 5
[RFC 2535] - D. Eastlake, "Domain Name System Security Extensions", [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",
March 1999. March 1999.
[draft-ietf-dnsind-tsig-*.txt] - P. Vixie, O. Gudmundsson, D. [draft-ietf-dnsind-tsig-*.txt] - P. Vixie, O. Gudmundsson, D.
Eastlake, B. Wellington, "Secret Key Transaction Signatures for DNS Eastlake, B. Wellington, "Secret Key Transaction Signatures for DNS
(TSIG)". (TSIG)".
[draft-ietf-dnsind-tkey-*.txt] - D. Eastlake, "Secret Key [draft-ietf-dnsind-tkey-*.txt] - D. Eastlake, "Secret Key
Establishment for DNS (RR)" Establishment for DNS (RR)"
*
Author's Address Author's Address
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
IBM IBM
65 Shindegan Hill Road 65 Shindegan Hill Road
Carmel, NY 10512 USA Carmel, NY 10512 USA
Telephone: +1-914-784-7913(w) Telephone: +1-914-276-2668(h)
+1-914-276-2668(h) +1-914-784-7913(w)
fax: +1-914-784-3833(w) fax: +1-914-276-2947(h)
email: dee3@us.ibm.com email: dee3@us.ibm.com
Expiration and File Name Expiration and File Name
This draft expires April 2000. This draft expires June 2000.
Its file name is draft-ietf-dnsind-sig-zero-00.txt. Its file name is draft-ietf-dnsind-sig-zero-01.txt.
Appendix: SIG(0) Changes from RFC 2535 Appendix: SIG(0) Changes from RFC 2535
Add explanatory text concerning the differences between TSIG and Add explanatory text concerning the differences between TSIG and
SIG(0). SIG(0).
Change the data over which SIG(0) is calculated to include the SIG(0) Change the data over which SIG(0) is calculated to include the SIG(0)
RDATA other than the signature itself to secure the signature RDATA other than the signature itself to secure the signature
inception and expiration times and resist replay attacks. Specify inception and expiration times and resist replay attacks. Specify
SIG(0) for TCP. SIG(0) for TCP.
Add discussion of appropriate inception and expiration times for Add discussion of appropriate inception and expiration times for
SIG(0). SIG(0).
Change wording to permit mixing TSIG and SIG(0) RRs. Change wording to permit mixing TSIG and SIG(0) RRs.
Reword some areas for clarity. Reword some areas for clarity.
*
Status of This Document....................................1
Abstract...................................................1
Acknowledgments............................................2
Table of Contents..........................................2
1. Introduction............................................3
2. SIG(0) Design Rational..................................4
2.1 Differences Between TSIG and SIG(0)....................4
3. The SIG(0) Resource Record..............................6
3.1 Calculating Request and Transaction SIGs...............6
3.2 Processing Responses and SIG(0) RRs....................7
3.3 SIG(0) Lifetime and Expiration.........................8
4. Security Considerations.................................9
5. IANA Considerations.....................................9
References.................................................9
Author's Address..........................................10
Expiration and File Name..................................10
Appendix: SIG(0) Changes from RFC 2535....................10
*
 End of changes. 36 change blocks. 
119 lines changed or deleted 148 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/