< draft-msahli-ise-ieee1609-00.txt   draft-msahli-ise-ieee1609-01.txt >
Network Working Group M. Msahli, Ed. Network Working Group M. Msahli, Ed.
Internet-Draft Telecom ParisTech Internet-Draft Telecom ParisTech
Intended status: Experimental N. Cam-Winget, Ed. Intended status: Experimental N. Cam-Winget, Ed.
Expires: January 23, 2020 Cisco Expires: February 15, 2020 Cisco
July 22, 2019 August 14, 2019
TLS Authentication using IEEE 1609.2 certificates TLS Authentication using IEEE 1609.2 certificate
draft-msahli-ise-ieee1609-00 draft-msahli-ise-ieee1609-01
Abstract Abstract
This document specifies the use of a new certificate type to This document specifies the use of the IEEE/ETSI certificate type to
authenticate TLS entities. The goal is to enable the use of a authenticate TLS entities. The goal is to enable the use of end-
certificate specified by the IEEE and the European Telecommunications entity certificate specified by the IEEE and the European
Standards Institute (ETSI). This specification defines an Telecommunications Standards Institute (ETSI). This specification
experimental change of TLS to support a new certificate type. defines an experimental change of TLS to support IEEE/ETSI
certificate type.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 January 23, 2020. This Internet-Draft will expire on February 15, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
4.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . 6
5. Certificate Verification . . . . . . . . . . . . . . . . . . 7 5. Certificate Verification . . . . . . . . . . . . . . . . . . 7
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. TLS Server and TLS Client use the 1609Dot2 Certificate . 8 6.1. TLS Server and TLS Client use the 1609Dot2 Certificate . 8
6.2. TLS Client uses the IEEE 1609.2 certificate and TLS 6.2. TLS Client uses the IEEE 1609.2 certificate and TLS
Server uses the X.509 certificate . . . . . . . . . . . . 8 Server uses the X.509 certificate . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. Normative References . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The TLS protocol [RFC8446] uses X.509 and Raw Public Key in order to The TLS protocol [RFC8446] [RFC5246] uses X.509 certificates and Raw
authenticate servers and clients. This document describes an Public Key in order to authenticate servers and clients. This
experimental use of the certificate specified by the IEEE in document describes an experimental extension following the [RFC7250]
to support use of the certificate format specified by the IEEE in
[IEEE1609.2] and profiled by the European Telecommunications [IEEE1609.2] and profiled by the European Telecommunications
Standards Institute (ETSI) in [TS103097]. These standards specify Standards Institute (ETSI) in [TS103097]. These standards specify
secure communications in vehicular environments. The certificate secure communications in vehicular environments. The certificate
types are optimized for bandwidth and processing time to support types are optimized for bandwidth and processing time to support
delay-sensitive applications, and also to provide both authentication delay-sensitive applications, and also to provide both authentication
and authorization information to enable fast access control decisions and authorization information to enable fast access control decisions
in ad hoc networks such as are found in Intelligent Transportation in ad hoc networks such as are found in Intelligent Transportation
System (ITS). We define an experimental extension following the Systems (ITS). The standards specify different types of certificate
[RFC7250]. to support a full Public Key Infrastructure (PKI) specification; the
certificates to be used in this context are end-entity certificates,
i.e. certificates that have the 1609.2 appPermissions field present.
1.1. Experiment Overview 1.1. Experiment Overview
This document describes an experimental extension of TLS security This document describes an experimental extension of TLS security
model. We are using a form of certificate that has not traditionally model. We are using a form of certificate that has not traditionally
been used in IETF works. Systems using this Experimental approach been used in the Internet. Systems using this Experimental approach
are segregated from system using standard TLS by the use of a new are segregated from system using standard TLS by the use of a new
Certificate Type value, reserved through IANA. The implementation of Certificate Type value, reserved through IANA. The implementation of
TLS is not involved in the Experiment and it will not be able to TLS is not involved in the Experiment and it will not be able to
interact with an Experimental implementation. In fact, an interact with an Experimental implementation. In fact, an
implementation of TLS can recognize that the Certificate Type value implementation of TLS can recognize that the Certificate Type value
used in this document is unknown. This design has been requested by used in this document is unknown. This extension has been encouraged
stakeholders in the Cooperative ITS community including ISO by stakeholders in the Cooperative ITS community including ISO
internationally, and SAE in the US and ETSI in EU , in order to internationally, and SAE in the US and ETSI in EU , in order to
support the deployment of a number of use cases in cooperative ITS support the deployment of a number of use cases in cooperative ITS
and it is anticipated that its use will be widespread. and it is anticipated that its use will be widespread.
There is no IPR that needs to be disclosed by the authors or
contributors under the IETF's rules set out in BCP 78 and BCP 79.
2. Requirements Terminology 2. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174]when, and only when, they appear in all 14 [RFC2119] [RFC8174]when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Extension Overview 3. Extension Overview
skipping to change at page 4, line 35 skipping to change at page 4, line 35
case X.509: case X.509:
opaque cert_data<1..2^24-1>; opaque cert_data<1..2^24-1>;
}; };
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
} CertificateEntry; } CertificateEntry;
In case where the TLS server accepts the described extension, it In case where the TLS server accepts the described extension, it
selects one of the certificate types. Note that a server MAY selects one of the certificate types. Note that a server MAY
authenticate the client using other authentication methods. The end- authenticate the client using other authentication methods.
entity certificate's public key MUST be compatible with one of the
certificate types listed in the extension described above.
4. TLS Client and Server Handshake 4. TLS Client and Server Handshake
The "client_certificate_type" and "server_certificate_type" The "client_certificate_type" and "server_certificate_type"
extensions MUST be sent in handshake phase as illustrated in figure 1 extensions MUST be sent in handshake phase as illustrated in figure 1
below. below.
Client Server Client Server
Key ^ ClientHello Key ^ ClientHello
skipping to change at page 6, line 9 skipping to change at page 6, line 9
1609.2 or ETSI TS 103097 certificate-based authentication, the 1609.2 or ETSI TS 103097 certificate-based authentication, the
clients and the servers MAY include the extension of type clients and the servers MAY include the extension of type
"client_certificate_type" and "server_certificate_type" in the "client_certificate_type" and "server_certificate_type" in the
extended Client Hello and "EncryptedExtensions". In case of TLS 1.2, extended Client Hello and "EncryptedExtensions". In case of TLS 1.2,
used extensions are in Client Hello and Server Hello. used extensions are in Client Hello and Server Hello.
4.1. Client Hello 4.1. Client Hello
In order to indicate the support of IEEE 1609.2 or ETSI TS 103097 In order to indicate the support of IEEE 1609.2 or ETSI TS 103097
certificates, client MUST include an extension of type certificates, client MUST include an extension of type
"client_certificate_type" and "server_certificate_type" in the "client_certificate_type" or "server_certificate_type" in the
extended Client Hello message. The Hello extension is described in extended Client Hello message as described in Section 4.1.2 of TLS
Section 4.1.2 of TLS 1.3 [RFC8446]. 1.3 [RFC8446].
The extension 'client_certificate_type' sent in the client hello MAY The extension 'client_certificate_type' sent in the Client Hello MAY
carry a list of supported certificate types, sorted by client carry a list of supported certificate types, sorted by client
preference. It is a list in the case where the client supports preference. It is a list in the case where the client supports
multiple certificate types. multiple certificate types.
In both TLS 1.2 and 1.3, the rules if client Certificate and In both TLS 1.2 and 1.3, the rules if client Certificate and
CertificateVerify messages appear is as follows: CertificateVerify messages appear is as follows:
- Client Certificate message is present if and only if server sent - Client Certificate message is present if and only if server sent
a CertificateRequest message. a CertificateRequest message.
skipping to change at page 6, line 48 skipping to change at page 6, line 48
- The server supports the extension described in this document. - The server supports the extension described in this document.
It selects a certificate type from the client_certificate_type It selects a certificate type from the client_certificate_type
field in the extended Client Hello and SHALL take into account the field in the extended Client Hello and SHALL take into account the
client authentication list priority. client authentication list priority.
- The server does not support any of the proposed certificate type - The server does not support any of the proposed certificate type
and terminates the session with a fatal alert of type and terminates the session with a fatal alert of type
"unsupported_certificate". "unsupported_certificate".
- The server does not support the extension defined in this - The server does not support the extension defined in this
document. In this case, the server returns the server hello document. In this case, the server returns the Server Hello
without the extensions defined in this document. without the extensions defined in this document.
- The server supports the extension defined in this document, but - The server supports the extension defined in this document, but
it does not have any certificate type in common with the client. it does not have any certificate type in common with the client.
Then, the server terminates the session with a fatal alert of type Then, the server terminates the session with a fatal alert of type
"unsupported_certificate". "unsupported_certificate".
- The server supports the extensions defined in this document and - The server supports the extensions defined in this document and
has at least one certificate type in common with the client. In has at least one certificate type in common with the client. In
skipping to change at page 7, line 26 skipping to change at page 7, line 26
obtained from an online repository. obtained from an online repository.
5. Certificate Verification 5. Certificate Verification
Verification of an IEEE 1609.2/ ETSI TS 103097 certificates or Verification of an IEEE 1609.2/ ETSI TS 103097 certificates or
certificate chain is described in section 5.1 of [IEEE1609.2]. In certificate chain is described in section 5.1 of [IEEE1609.2]. In
the case of TLS 1.3 and when the certificate_type is 1609Dot2, the the case of TLS 1.3 and when the certificate_type is 1609Dot2, the
CertificateVerify contents and processing are different than for the CertificateVerify contents and processing are different than for the
CertificateVerify message specified for other values of CertificateVerify message specified for other values of
certificate_type in [RFC8446]. In this case, the CertificateVerify certificate_type in [RFC8446]. In this case, the CertificateVerify
message contains a Canonical Octet Encoding Rules (COER)-encoded message contains a Canonical Octet Encoding Rules (COER)[ITU-TX.696]
Ieee1609Dot2Data of type signed as specified in [IEEE1609.2], -encoded IEEE1609Dot2Data of type signed as specified in
[IEEE1609.2b], where: [IEEE1609.2], [IEEE1609.2b], where:
payload contains an extDataHash containing the SHA-256 hash of the payload contains an extDataHash containing the SHA-256 hash of the
data the signature is calculated over. This is identical to the data the signature is calculated over. This is identical to the
data the signature is calculated over in standard TLS, which is data the signature is calculated over in standard TLS, which is
reproduced below for clarity. reproduced below for clarity.
psid indicates the application activity that the certificate is psid indicates the application activity that the certificate is
authorizing. authorizing.
generationTime is the current time. generationTime is the current time.
pduFunctionalType (as specified in [IEEE1609.2b]) is present and pduFunctionalType (as specified in [IEEE1609.2b]) is present and
is set equal to tlsHandshake (1). is set equal to tlsHandshake (1).
All other fields in the headerInfo are omitted. All other fields in the headerInfo are omitted.
The certificate appPermissions field shall be present and shall
permit (as defined in 1609.2) signing of PDUs with the PSID indicated
in the HeaderInfo of the SignedData. If the application
specification for that PSID requires Service Specific Permissions
(SSP) for signing a pduFunctionalType of tlsHandsahke, this SSP shall
also be present.
The message input to the signature calculation is the usual message The message input to the signature calculation is the usual message
input for TLS 1.3, as specified in [RFC8446] section 4.4.3, input for TLS 1.3, as specified in [RFC8446] section 4.4.3,
consisting of pad, context string, separator and content, where consisting of pad, context string, separator and content, where
content is Transcript- Hash(Handshake Context, Certificate). content is Transcript- Hash(Handshake Context, Certificate).
The signature and verification are carried out as specified in The signature and verification are carried out as specified in
[IEEE1609.2]. [IEEE1609.2].
6. Examples 6. Examples
skipping to change at page 8, line 21 skipping to change at page 8, line 29
This section shows an example where the TLS client as well as the TLS This section shows an example where the TLS client as well as the TLS
server use the IEEE 1609.2 certificate. In consequence, both the server use the IEEE 1609.2 certificate. In consequence, both the
server and the client populate the client_certificate_type and server and the client populate the client_certificate_type and
server_certificate_type with extension IEEE 1609.2 certificates as server_certificate_type with extension IEEE 1609.2 certificates as
mentioned in figure 2. mentioned in figure 2.
Client Server Client Server
ClientHello, ClientHello,
client_certificate_type*=1609Dot2, client_certificate_type=1609Dot2,
server_certificate_type*=1609Dot2, --------> ServerHello, server_certificate_type=1609Dot2, --------> ServerHello,
{EncryptedExtensions} {EncryptedExtensions}
{client_certificate_type*=1609Dot2} {client_certificate_type=1609Dot2}
{server_certificate_type*=1609Dot2} {server_certificate_type=1609Dot2}
{CertificateRequest*} {CertificateRequest}
{Certificate*} {Certificate}
{CertificateVerify*} {CertificateVerify}
{Finished} {Finished}
{Certificate*} <------- [Application Data*] {Certificate} <------- [Application Data]
{CertificateVerify*} {CertificateVerify}
{Finished} --------> {Finished} -------->
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
Figure 2: TLS Client and TLS Server use the IEEE 1609.2 certificate Figure 2: TLS Client and TLS Server use the IEEE 1609.2 certificate
6.2. TLS Client uses the IEEE 1609.2 certificate and TLS Server uses 6.2. TLS Client uses the IEEE 1609.2 certificate and TLS Server uses
the X.509 certificate the X.509 certificate
This example shows the TLS authentication, where the TLS Client This example shows the TLS authentication, where the TLS Client
populates the server_certificate_type extension with the X.509 populates the server_certificate_type extension with the X.509
certificate and Raw Public Key type as presented in figure 3. the certificate and Raw Public Key type as presented in figure 3. the
client indicates its ability to receive and to validate an X.509 client indicates its ability to receive and to validate an X.509
certificate from the server. The server chooses the X.509 certificate from the server. The server chooses the X.509
certificate to make its authentication with the Client. certificate to make its authentication with the Client.
Client Server Client Server
ClientHello, ClientHello,
client_certificate_type*=(1609Dot2), client_certificate_type=(1609Dot2),
server_certificate_type*=(1609.9Dot, server_certificate_type=(1609.9Dot,
X509,RawPublicKey), -----------> ServerHello, X509,RawPublicKey), -----------> ServerHello,
{EncryptedExtensions} {EncryptedExtensions}
{client_certificate_type*=1609Dot2} {client_certificate_type=1609Dot2}
{server_certificate_type*=X509} {server_certificate_type=X509}
{Certificate*} {Certificate}
{CertificateVerify*} {CertificateVerify}
{Finished} {Finished}
<--------- [Application Data*] <--------- [Application Data]
{Finished} ---------> {Finished} --------->
[Application Data] <--------> [Application Data] [Application Data] <--------> [Application Data]
Figure 3: TLS Client uses the IEEE 1609.2 certificate and TLS Server Figure 3: TLS Client uses the IEEE 1609.2 certificate and TLS Server
uses the X.509 certificate uses the X.509 certificate
7. Security Considerations 7. Security Considerations
This section provides an overview of the basic security This section provides an overview of the basic security
considerations which need to be taken into account before considerations which need to be taken into account before
skipping to change at page 9, line 39 skipping to change at page 9, line 41
groups and signature algorithms apply here as well. groups and signature algorithms apply here as well.
TLS extensions to be considered are: TLS extensions to be considered are:
The "client_certificate_type" [IANA value 19] extension who's The "client_certificate_type" [IANA value 19] extension who's
purpose was previously described in [RFC7250]. purpose was previously described in [RFC7250].
The "server_certificate_type" [IANA value 20] extension who's The "server_certificate_type" [IANA value 20] extension who's
purpose was previously described in [RFC7250]. purpose was previously described in [RFC7250].
This specification does not address the security of online
repository.
8. Privacy Considerations 8. Privacy Considerations
For privacy considerations in a vehicular environment the use of IEEE For privacy considerations in a vehicular environment the use of IEEE
1609.2/ETSI TS 103097 certificate is recommended for many reasons: 1609.2/ETSI TS 103097 certificate is recommended for many reasons:
In order to address the risk of a personal data leakage, messages In order to address the risk of a personal data leakage, messages
exchanged for V2V communications are signed using IEEE 1609.2/ETSI exchanged for V2V communications are signed using IEEE 1609.2/ETSI
TS 103097 pseudonym certificates TS 103097 pseudonym certificates
The purpose of these certificates is to provide privacy relying on The purpose of these certificates is to provide privacy relying on
geographical and/or temporal validity criteria, and minimizing the geographical and/or temporal validity criteria, and minimizing the
exchange of private data exchange of private data
9. IANA Considerations 9. IANA Considerations
IANA is requested to update the registry to reference the RFC. IANA is requested to update the registry to reference the RFC:
https://www.iana.org/assignments/tls-extensiontype-values/tls-
Existing IANA references have not been updated yet to point to this extensiontype-values.xhtml to point to this document.
document.
10. Acknowledgements 10. Acknowledgements
The authors wish to thank Eric Rescola and Ilari Liusvaara for their The authors wish to thank Eric Rescola , Russ Housley and Ilari
feedback and suggestions on improving this document. Thanks are due Liusvaara for their feedback and suggestions on improving this
to Sean Turner for his valuable and detailed comments. Special document. Thanks are due to Sean Turner for his valuable and
thanks to Panos Kampanakis, Jasja Tijink and Maik Seewald for their detailed comments. Special thanks to Panos Kampanakis, Jasja Tijink
guidance and support of the draft. and Maik Seewald for their guidance and support of the draft.
11. References
11.1. Normative References 11. Normative References
[IEEE1609.2] [IEEE1609.2]
"IEEE Standard for Wireless Access in Vehicular "IEEE Standard for Wireless Access in Vehicular
Environments - Security Services for Applications and Environments - Security Services for Applications and
Management Messages", 2016. Management Messages", 2016.
[IEEE1609.2b] [IEEE1609.2b]
"IEEE Standard for Wireless Access in Vehicular "IEEE Standard for Wireless Access in Vehicular
Environments--Security Services for Applications and Environments--Security Services for Applications and
Management Messages - Amendment 2--PDU Functional Types Management Messages - Amendment 2--PDU Functional Types
and Encryption Key Management", 2019. and Encryption Key Management", 2019.
[ITU-TX.696]
"Procedures for the operation of object identifier
registration authorities: General procedures and top arcs
of the international object identifier tree", July 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997. Requirement Levels", March 1997.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", August 2008. (TLS) Protocol Version 1.2", August 2008.
[RFC7250] Wouters, P., Tschofenig, H., Weiler, S., and T. Kivinen, [RFC7250] Wouters, P., Tschofenig, H., Weiler, S., and T. Kivinen,
"Using Raw Public Keys in Transport Layer Security (TLS) "Using Raw Public Keys in Transport Layer Security (TLS)
and Datagram Transport Layer Security (DTLS)", June 2014. and Datagram Transport Layer Security (DTLS)", June 2014.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", May 2017. 2119 Key Words", May 2017.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", August 2018. Version 1.3", August 2018.
[TS103097] [TS103097]
"ETSI TS 103 097 : Intelligent Transport Systems (ITS); "ETSI TS 103 097 : Intelligent Transport Systems (ITS);
Security; Security header and certificate formats". Security; Security header and certificate formats".
11.2. Informative References
[draft-serhrouchni-tls-certieee1609-00]
KAISER, A., LABIOD, H., LONC, B., MSAHLI, M., and A.
SERHROUCHNI, "Transport Layer Security (TLS)
Authentication using ITS ETSI and IEEE certificates",
august 2017.
Appendix A. Contributors Appendix A. Contributors
o Houda Labiod o Houda Labiod
Telecom ParisTech Telecom ParisTech
houda.labiod@telecom-paristech.fr houda.labiod@telecom-paristech.fr
o Ahmed Serhrouchni o Ahmed Serhrouchni
Telecom ParisTech Telecom ParisTech
ahmed.serhrouchni@telecom-paristech.fr ahmed.serhrouchni@telecom-paristech.fr
 End of changes. 27 change blocks. 
74 lines changed or deleted 75 lines changed or added

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