draft-ietf-kitten-cammac-00.txt   draft-ietf-kitten-cammac-01.txt 
Internet Engineering Task Force S. Sorce, Ed. Internet Engineering Task Force S. Sorce, Ed.
Internet-Draft Red Hat Internet-Draft Red Hat
Updates: 4120 (if approved) T. Yu, Ed. Updates: 4120 (if approved) T. Yu, Ed.
Intended status: Standards Track T. Hardjono, Ed. Intended status: Standards Track T. Hardjono, Ed.
Expires: May 16, 2015 MIT Kerberos Consortium Expires: July 9, 2015 MIT Kerberos Consortium
November 12, 2014 January 5, 2015
Kerberos Authorization Data Container Authenticated by Multiple MACs Kerberos Authorization Data Container Authenticated by Multiple MACs
draft-ietf-kitten-cammac-00 draft-ietf-kitten-cammac-01
Abstract Abstract
Abstract: This document specifies a Kerberos Authorization Data This document specifies a Kerberos Authorization Data container that
container that supersedes AD-KDC-ISSUED. It allows for multiple supersedes AD-KDC-ISSUED. It allows for multiple Message
Message Authentication Codes (MACs) or signatures to authenticate the Authentication Codes (MACs) or signatures to authenticate the
contained Authorization Data elements. This document updates RFC contained Authorization Data elements. The multiple MACs are needed
4120. to mitigate shortcomings in the existing AD-KDC-ISSUED container.
This document updates RFC 4120.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 16, 2015. This Internet-Draft will expire on July 9, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 20 skipping to change at page 2, line 21
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Assigned numbers . . . . . . . . . . . . . . . . . . . . . . 6 6. Assigned numbers . . . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
This document specifies a new Authorization Data container for This document specifies a new Authorization Data container for
Kerberos, called AD-CAMMAC (Container Authenticated by Multiple Kerberos, called the CAMMAC (Container Authenticated by Multiple
MACs), that supersedes AD-KDC-ISSUED. This new container allows both MACs). The ASN.1 type implementing the CAMMAC concept is the AD-
the receiving application service and the Key Distribution Center CAMMAC, which supersedes the AD-KDC-ISSUED Authorization Data type
(KDC) itself to verify the authenticity of the contained specified in [RFC4120]. This new container allows both the receiving
authorization data. The AD-CAMMAC container can also include application service and the Key Distribution Center (KDC) itself to
additional verifiers that "trusted services" can use to verify the verify the authenticity of the contained authorization data. The AD-
contained authorization data. CAMMAC container can also include additional verifiers that "trusted
services" can use to verify the contained authorization data.
2. Requirements Language 2. Requirements Language
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 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Motivations 3. Motivations
The Kerberos protocol allows clients to submit arbitrary The Kerberos protocol allows clients to submit arbitrary
skipping to change at page 3, line 30 skipping to change at page 3, line 33
the evidence ticket constitute a flow of authorization data from the the evidence ticket constitute a flow of authorization data from the
application service to the KDC. The properties of the AD-KDC-ISSUED application service to the KDC. The properties of the AD-KDC-ISSUED
container are insufficient for this use case because the service container are insufficient for this use case because the service
knows the symmetric key for the checksum in the AD-KDC-ISSUED knows the symmetric key for the checksum in the AD-KDC-ISSUED
container. Therefore, the KDC has no way to detect whether the container. Therefore, the KDC has no way to detect whether the
service has tampered with the contents of the AD-KDC-ISSUED container service has tampered with the contents of the AD-KDC-ISSUED container
within the evidence ticket. within the evidence ticket.
The new AD-CAMMAC authorization data container specified in this The new AD-CAMMAC authorization data container specified in this
document improves upon AD-KDC-ISSUED by including additional verifier document improves upon AD-KDC-ISSUED by including additional verifier
elements. The svc-verifier element of the CAMMAC has the same elements. The svc-verifier (service verifier) element of the AD-
functional and security properties as the ad-checksum element of AD- CAMMAC has the same functional and security properties as the ad-
KDC-ISSUED; the svc-verifier allows the service to verify the checksum element of AD-KDC-ISSUED; the svc-verifier allows the
integrity of the AD-CAMMAC contents as it already could with the AD- service to verify the integrity of the AD-CAMMAC contents as it
KDC-ISSUED container. The kdc-verifier and other-verifiers elements already could with the AD-KDC-ISSUED container. The kdc-verifier and
are new to AD-CAMMAC and provide its enhanced capabilities. other-verifiers elements are new to AD-CAMMAC and provide its
enhanced capabilities.
The kdc-verifier element of the AD-CAMMAC container allows a KDC to The kdc-verifier element of the AD-CAMMAC container allows a KDC to
verify the integrity of authorization data that it previously verify the integrity of authorization data that it previously
inserted into a ticket, by using a key that only the KDC knows. The inserted into a ticket, by using a key that only the KDC knows. The
KDC thus avoids recomputing all of the authorization data for the KDC thus avoids recomputing all of the authorization data for the
issued ticket; this operation might not always be possible when that issued ticket; this recomputation might not always be possible when
data includes ephemeral information such as the strength or type of that data includes ephemeral information such as the strength or type
authentication method used to obtain the original ticket. of authentication method used to obtain the original ticket.
The verifiers in the other-verifiers element of the AD-CAMMAC The verifiers in the other-verifiers element of the AD-CAMMAC
container are not required, but can be useful when a lesser- container are not required, but can be useful when a lesser-
privileged service receives a ticket from a client and needs to privileged service receives a ticket from a client and needs to
extract the CAMMAC to demonstrate to a higher-privileged "trusted extract the AD-CAMMAC to demonstrate to a higher-privileged "trusted
service" on the same host that it is legitimately acting on behalf of service" on the same host that it is legitimately acting on behalf of
that client. The trusted service can use a verifier in the other- that client. The trusted service can use a verifier in the other-
verifiers element to validate the contents of the CAMMAC without verifiers element to validate the contents of the AD-CAMMAC without
further communication with the KDC. further communication with the KDC.
4. Encoding 4. Encoding
The Kerberos protocol is defined in [RFC4120] using Abstract Syntax The Kerberos protocol is defined in [RFC4120] using Abstract Syntax
Notation One (ASN.1) [X.680] and using the ASN.1 Distinguished Notation One (ASN.1) [X.680] and using the ASN.1 Distinguished
Encoding Rules (DER) [X.690]. For consistency, this specification Encoding Rules (DER) [X.690]. For consistency, this specification
also uses ASN.1 for specifying the layout of AD-CAMMAC. The ad-data also uses ASN.1 for specifying the layout of AD-CAMMAC. The ad-data
of the AD-CAMMAC authorization data element is the ASN.1 DER encoding of the AD-CAMMAC authorization data element is the ASN.1 DER encoding
of the AD-CAMMAC ASN.1 type specified below. of the AD-CAMMAC ASN.1 type specified below.
skipping to change at page 5, line 23 skipping to change at page 5, line 24
Verifier-MAC: Verifier-MAC:
Contains an RFC 3961 [RFC3961] Checksum (MAC) computed over the Contains an RFC 3961 [RFC3961] Checksum (MAC) computed over the
ASN.1 DER encoding of the AuthorizationData value in the elements ASN.1 DER encoding of the AuthorizationData value in the elements
field of the AD-CAMMAC. The identifier, kvno, and enctype fields field of the AD-CAMMAC. The identifier, kvno, and enctype fields
help the recipient locate the key required for verifying the MAC. help the recipient locate the key required for verifying the MAC.
For the kdc-verifier and the svc-verifier, the identifier, kvno For the kdc-verifier and the svc-verifier, the identifier, kvno
and enctype fields are often obvious from context and MAY be and enctype fields are often obvious from context and MAY be
omitted. For the kdc-verifier, the MAC is computed differently omitted. For the kdc-verifier, the MAC is computed differently
than for the svc-verifier and the other-verifiers, as described than for the svc-verifier and the other-verifiers, as described
later. The key usage for computing the MAC (Checksum) is 64. later. The key usage number for computing the MAC (Checksum) is
64.
kdc-verifier: kdc-verifier:
A Verifier-MAC where the key is a long-term key of the local A Verifier-MAC where the key is a long-term key of the local
Ticket-Granting Service (TGS). The checksum type is the required Ticket-Granting Service (TGS). The checksum type is the required
checksum type for the enctype of the TGS key. In contrast to the checksum type for the enctype of the TGS key. In contrast to the
other Verifier-MAC elements, the KDC computes the MAC in the kdc- other Verifier-MAC elements, the KDC computes the MAC in the kdc-
verifier over the ASN.1 DER encoding of the EncTicketPart of the verifier over the ASN.1 DER encoding of the EncTicketPart of the
surrounding ticket, but where the AuthorizationData value in the surrounding ticket, but where the AuthorizationData value in the
EncTicketPart contains the AuthorizationData value contained in EncTicketPart contains the AuthorizationData value contained in
the CAMMAC instead of the AuthorizationData value that would the AD-CAMMAC instead of the AuthorizationData value that would
otherwise be present in the ticket. This altered Verifier-MAC otherwise be present in the ticket. This altered Verifier-MAC
computation binds the kdc-verifier to the other contents of the computation binds the kdc-verifier to the other contents of the
ticket, assuring the KDC that a malicious service has not ticket, assuring the KDC that a malicious service has not
substituted a mismatched CAMMAC received from another ticket. substituted a mismatched AD-CAMMAC received from another ticket.
svc-verifier: svc-verifier:
A Verifier-MAC where the key is the same long-term service key A Verifier-MAC where the key is the same long-term service key
that the KDC uses to encrypt the surrounding ticket. The checksum that the KDC uses to encrypt the surrounding ticket. The checksum
type is the required checksum type for the enctype of the service type is the required checksum type for the enctype of the service
key used to encrypt the ticket. This field MUST be present if the key used to encrypt the ticket. This field MUST be present if the
service principal of the ticket is not the local TGS, including service principal of the ticket is not the local TGS, including
when the ticket is a cross-realm TGT. when the ticket is a cross-realm Ticket-Granting Ticket (TGT).
other-verifiers: other-verifiers:
A sequence of additional verifiers. In each additional Verifier- A sequence of additional verifiers. In each additional Verifier-
MAC, the key is a long-term key of the principal name specified in MAC, the key is a long-term key of the principal name specified in
the identifier field. The PrincipalName MUST be present and be a the identifier field. The PrincipalName MUST be present and be a
valid principal in the realm. KDCs MAY add one or more "trusted valid principal in the realm. KDCs MAY add one or more "trusted
service" verifiers. Unless otherwise administratively configured, service" verifiers. Unless otherwise administratively configured,
the KDC SHOULD determine the "trusted service" principal name by the KDC SHOULD determine the "trusted service" principal name by
replacing the service identifier component of the sname of the replacing the service identifier component of the sname of the
surrounding ticket with "host". The checksum is computed using a surrounding ticket with "host". The checksum is computed using a
long-term key of the identified principal, and the checksum type long-term key of the identified principal, and the checksum type
is the required checksum type for the enctype of that long-term is the required checksum type for the enctype of that long-term
key. The kvno and enctype SHOULD be specified to disambiguate key. The kvno and enctype SHOULD be specified to disambiguate
which of the long-term keys of the trusted service is used. which of the long-term keys of the trusted service is used.
5. Usage 5. Usage
Application servers and KDCs MAY ignore the AD-CAMMAC container and Application servers and KDCs MAY ignore the AD-CAMMAC container and
the authorization data elements it contains. For compatibility with the authorization data elements it contains. For compatibility with
older Kerberos implementations, a KDC issuing an AD-CAMMAC SHOULD older Kerberos implementations, a KDC issuing an AD-CAMMAC SHOULD
enclose it in an AD-IF-RELEVANT container unless the KDC knows that enclose it in an AD-IF-RELEVANT container [RFC4120] unless the KDC
the application server is likely to recognize it. knows that the application server is likely to recognize it.
6. Assigned numbers 6. Assigned numbers
The ad-type number for AD-CAMMAC is 96. RFC 4120 is updated in the following ways:
The key usage number for the Verifier-MAC checksum is 64. o The ad-type number 96 is assigned for AD-CAMMAC, updating the
table in Section 7.5.4 of [RFC4120].
o The table in Section 5.2.6 of [RFC4120] is updated to map the ad-
type 96 to "DER encoding of AD-CAMMAC".
o The key usage number 64 is assigned for the Verifier-MAC checksum,
updating the table in Section 7.5.1 of [RFC4120].
7. IANA Considerations 7. IANA Considerations
[ RFC Editor: please remove this section prior to publication. ] [ RFC Editor: please remove this section prior to publication. ]
There are no IANA considerations in this document. Any numbers There are no IANA considerations in this document. Any numbers
assigned in this document are not in IANA-controlled number spaces. assigned in this document are not in IANA-controlled number spaces.
8. Security Considerations 8. Security Considerations
The CAMMAC provides data origin authentication for authorization data
contained in it, attesting that it originated from the KDC. This
section describes the precautions required to maintain the integrity
of that data origin authentication through various information flows
involving a Kerberos ticket containing a CAMMAC.
Although authorization data are generally conveyed within the Although authorization data are generally conveyed within the
encrypted part of a ticket and are thereby protected by the existing encrypted part of a ticket and are thereby protected by the existing
encryption scheme used for the surrounding ticket, some authorization encryption scheme used for the surrounding ticket, some authorization
data requires the additional protection provided by the CAMMAC. data requires the additional protection provided by the CAMMAC.
Some protocol extensions such as S4U2Proxy allow the KDC to issue a Some protocol extensions such as S4U2Proxy allow the KDC to issue a
new ticket based on an evidence ticket provided by the service. If new ticket based on an evidence ticket provided by the service. If
the evidence ticket contains authorization data that needs to be the evidence ticket contains authorization data that needs to be
preserved in the new ticket, then the KDC MUST revalidate it. preserved in the new ticket, then the KDC MUST verify the kdc-
verifier prior to copying the contained authorization data to a new
CAMMAC, except in the two situations enumerated below.
Extracting a CAMMAC from a ticket for use as a credential removes it Extracting a CAMMAC from a ticket for use as a credential removes it
from the context of the ticket. In the general case, this could turn from the context of the ticket. In the general case, this could turn
it into a bearer token, with all of the associated security it into a bearer token, with all of the associated security
implications. Also, the CAMMAC does not itself necessarily contain implications. Also, the CAMMAC does not itself necessarily contain
sufficient information to identify the client principal. Therefore, sufficient information to identify the client principal. Therefore,
application protocols that rely on extracted CAMMACs might need to application protocols that rely on extracted CAMMACs might need to
duplicate a substantial portion of the ticket contents and include duplicate a substantial portion of the ticket contents and include
that duplicated information in the authorization data contained that duplicated information in the authorization data contained
within the CAMMAC. The extent of this duplication would depend on within the CAMMAC. The extent of this duplication would depend on
the security properties required by the application protocol. the security properties required by the application protocol.
The method for computing the kdc-verifier does not bind it to any The method for computing the kdc-verifier binds it only to the
authorization data within the ticket but outside of the CAMMAC. At authorization data contained within the CAMMAC; it does not bind the
least one (non-standard) authorization data type, AD-SIGNEDPATH, CAMMAC to any authorization data within the containing ticket but
attempts to bind to other authorization data in a ticket, and it is outside the CAMMAC. At least one (non-standard) authorization data
very difficult for two such authorization data types to coexist. type, AD-SIGNEDPATH, attempts to bind to other authorization data in
a ticket, and it is very difficult for two such authorization data
types to coexist.
To minimize ticket size when embedding CAMMACs in Kerberos tickets, a To minimize ticket size when embedding CAMMACs in Kerberos tickets, a
KDC MAY omit the kdc-verifier from the CAMMAC when it is not needed. KDC MAY omit the kdc-verifier from the CAMMAC when it is not needed.
In this situation, the KDC cannot always determine whether the CAMMAC In this situation, the KDC cannot always determine whether the CAMMAC
contents are intact. The KDC MUST NOT create a new CAMMAC from an contents are intact. The KDC MUST NOT create a new CAMMAC from an
existing one unless the existing CAMMAC has a valid kdc-verifier, existing one unless the existing CAMMAC has a valid kdc-verifier,
with two exceptions. with two exceptions:
Only KDCs for the local realm have knowledge of the local TGS key, so 1. Only KDCs for the local realm have knowledge of the local TGS
the outer encryption of a local TGT is sufficient to protect the key, so the outer encryption of a local TGT is sufficient to
CAMMAC of a local TGT from tampering, assuming that all of the KDCs protect the CAMMAC of a local TGT from tampering, assuming that
in the local realm consistently filter out CAMMAC authorization data all of the KDCs in the local realm consistently filter out CAMMAC
submitted by clients. The KDC MAY create a new CAMMAC from an authorization data submitted by clients. The KDC MAY create a
existing CAMMAC lacking a kdc-verifier if that CAMMAC is contained new CAMMAC from an existing CAMMAC lacking a kdc-verifier if that
within a local TGT and all of the local realm KDCs are configured to CAMMAC is contained within a local TGT and all of the local realm
filter out CAMMAC authorization data submitted by clients. KDCs are configured to filter out CAMMAC authorization data
submitted by clients.
An application service might not use the S4U2Proxy extension, or the 2. An application service might not use the S4U2Proxy extension, or
realm policy might disallow the use of S4U2Proxy by that service. In the realm policy might disallow the use of S4U2Proxy by that
such situations where there is no flow of authorization data from the service. In such situations where there is no flow of
service to the KDC, the application service could modify the CAMMAC authorization data from the service to the KDC, the application
contents, but such modifications would have no effect on other service could modify the CAMMAC contents, but such modifications
services. Because of the lack of security impact, the KDC MAY create would have no effect on other services. Because of the lack of
a new CAMMAC from an existing CAMMAC lacking a kdc-verifier if it is security impact, the KDC MAY create a new CAMMAC from an existing
inserting the new CAMMAC into a service ticket for the same service CAMMAC lacking a kdc-verifier if it is inserting the new CAMMAC
principal as the ticket that contained the existing CAMMAC, but MUST into a service ticket for the same service principal as the
NOT place a kdc-verifier in the new CAMMAC. ticket that contained the existing CAMMAC, but MUST NOT place a
kdc-verifier in the new CAMMAC.
The kdc-verifier in CAMMAC does not bind the service principal name The kdc-verifier in CAMMAC does not bind the service principal name
to the CAMMAC contents, because the service principal name is not to the CAMMAC contents, because the service principal name is not
part of the EncTicketPart. An entity that has access to the keys of part of the EncTicketPart. An entity that has access to the keys of
two different service principals can decrypt a ticket for one service two different service principals can decrypt a ticket for one service
and encrypt it in the key of the other service, altering the svc- and encrypt it in the key of the other service, altering the svc-
verifier to match. Both the kdc-verifier and the svc-verifier would verifier to match. Both the kdc-verifier and the svc-verifier would
still validate, but the KDC never issued this fabricated ticket. The still validate, but the KDC never issued this fabricated ticket. The
impact of this manipulation is minor if the CAMMAC contents only impact of this manipulation is minor if the CAMMAC contents only
communicate attributes related to the client. If an application communicate attributes related to the client. If an application
requires an authenticated binding between the service principal name requires an authenticated binding between the service principal name
and the CAMMAC or ticket contents, the KDC MUST include in the CAMMAC and the CAMMAC or ticket contents, the KDC MUST include in the CAMMAC
some authorization data element that names the service principal. some authorization data element that names the service principal.
9. Acknowledgements 9. Acknowledgements
Shawn Emery, Sam Hartman, Greg Hudson, Ben Kaduk, Zhanna Tsitkov, and Shawn Emery, Sam Hartman, Greg Hudson, Ben Kaduk, Barry Leiba, Meral
Kai Zheng provided helpful technical and editorial feedback on Shirazipour, Zhanna Tsitkov, Qin Wu, and Kai Zheng provided helpful
earlier versions of this document. technical and editorial feedback on earlier versions of this
document.
10. References 10. References
10.1. Normative References 10.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.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, February 2005. Kerberos 5", RFC 3961, February 2005.
 End of changes. 25 change blocks. 
66 lines changed or deleted 90 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/