draft-ietf-httpbis-client-cert-field-03.txt   draft-ietf-httpbis-client-cert-field-latest.txt 
HTTP Working Group B. Campbell HTTP Working Group B. Campbell
Internet-Draft Ping Identity Internet-Draft Ping Identity
Intended status: Informational M. Bishop, Ed. Intended status: Informational M. Bishop, Ed.
Expires: April 22, 2023 Akamai Expires: May 15, 2023 Akamai
October 19, 2022 November 11, 2022
Client-Cert HTTP Header Field Client-Cert HTTP Header Field
draft-ietf-httpbis-client-cert-field-03 draft-ietf-httpbis-client-cert-field-latest
Abstract Abstract
This document defines HTTP extension header fields that allow a TLS This document describes HTTP extension header fields that allow a TLS
terminating reverse proxy to convey the client certificate terminating reverse proxy to convey the client certificate
information of a mutually-authenticated TLS connection to the origin information of a mutually-authenticated TLS connection to the origin
server in a common and predictable manner. server in a common and predictable manner.
About This Document About This Document
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
Status information for this document may be found at Status information for this document may be found at
<https://datatracker.ietf.org/doc/draft-ietf-httpbis-client-cert- <https://datatracker.ietf.org/doc/draft-ietf-httpbis-client-cert-
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 April 22, 2023. This Internet-Draft will expire on May 15, 2023.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 50 skipping to change at page 2, line 50
Although not exceedingly prevalent, TLS client certificate Although not exceedingly prevalent, TLS client certificate
authentication is sometimes employed and in such cases the origin authentication is sometimes employed and in such cases the origin
server often requires information about the client certificate for server often requires information about the client certificate for
its application logic. Such logic might include access control its application logic. Such logic might include access control
decisions, audit logging, and binding issued tokens or cookies to a decisions, audit logging, and binding issued tokens or cookies to a
certificate, and the respective validation of such bindings. The certificate, and the respective validation of such bindings. The
specific details from the certificate needed also vary with the specific details from the certificate needed also vary with the
application requirements. In order for these types of application application requirements. In order for these types of application
deployments to work in practice, the reverse proxy needs to convey deployments to work in practice, the reverse proxy needs to convey
information about the client certificate to the origin application information about the client certificate to the origin application
server. A common way this information is conveyed in practice today server. At the time of writing, a common way this information is
is by using non-standard fields to carry the certificate (in some conveyed is by using non-standard fields to carry the certificate (in
encoding) or individual parts thereof in the HTTP request that is some encoding) or individual parts thereof in the HTTP request that
dispatched to the origin server. This solution works but is dispatched to the origin server. This solution works but
interoperability between independently developed components can be interoperability between independently developed components can be
cumbersome or even impossible depending on the implementation choices cumbersome or even impossible depending on the implementation choices
respectively made (like what field names are used or are respectively made (like what field names are used or are
configurable, which parts of the certificate are exposed, or how the configurable, which parts of the certificate are exposed, or how the
certificate is encoded). A well-known predictable approach to this certificate is encoded). A well-known predictable approach to this
commonly occurring functionality could improve and simplify commonly occurring functionality could improve and simplify
interoperability between independent implementations. interoperability between independent implementations.
This document aspires to standardize two HTTP header fields, "Client- This document describes two HTTP header fields, "Client-Cert" and
Cert" and "Client-Cert-Chain", which a TLS terminating reverse proxy "Client-Cert-Chain", which a TLS terminating reverse proxy (TTRP)
(TTRP) adds to requests sent to the backend origin servers. The adds to requests sent to the backend origin servers. The "Client-
"Client-Cert" field value contains the end-entity client certificate Cert" field value contains the end-entity client certificate from the
from the mutually-authenticated TLS connection between the mutually-authenticated TLS connection between the originating client
originating client and the TTRP. Optionally, the "Client-Cert-Chain" and the TTRP. Optionally, the "Client-Cert-Chain" field value
field value contains the certificate chain used for validation of the contains the certificate chain used for validation of the end-entity
end-entity certificate. This enables the backend origin server to certificate. This enables the backend origin server to utilize the
utilize the client certificate information in its application logic. client certificate information in its application logic. While there
While there may be additional proxies or hops between the TTRP and may be additional proxies or hops between the TTRP and the origin
the origin server (potentially even with mutually-authenticated TLS server (potentially even with mutually-authenticated TLS connections
connections between them), the scope of the "Client-Cert" header between them), the scope of the "Client-Cert" header field is
field is intentionally limited to exposing to the origin server the intentionally limited to exposing to the origin server the
certificate that was presented by the originating client in its certificate that was presented by the originating client in its
connection to the TTRP. connection to the TTRP.
1.1. Requirements Notation and Conventions 1.1. Requirements Notation and Conventions
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 "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. Terminology and Applicability 1.2. Terminology and Applicability
This document uses the following terminology from Section 3 of
[STRUCTURED-FIELDS] to specify syntax and parsing: List and Byte
Sequence.
Phrases like TLS client certificate authentication or mutually- Phrases like TLS client certificate authentication or mutually-
authenticated TLS are used throughout this document to refer to the authenticated TLS are used throughout this document to refer to the
process whereby, in addition to the normal TLS server authentication process whereby, in addition to the normal TLS server authentication
with a certificate, a client presents its X.509 certificate [RFC5280] with a certificate, a client presents its X.509 certificate [RFC5280]
and proves possession of the corresponding private key to a server and proves possession of the corresponding private key to a server
when negotiating a TLS connection or the resumption of such a when negotiating a TLS connection or the resumption of such a
connection. In contemporary versions of TLS [TLS] [TLS1.2] this connection. In contemporary versions of TLS [TLS] [TLS1.2] this
requires that the client send the Certificate and CertificateVerify requires that the client send the Certificate and CertificateVerify
messages during the handshake and for the server to verify the messages during the handshake and for the server to verify the
CertificateVerify and Finished messages. CertificateVerify and Finished messages.
skipping to change at page 4, line 37 skipping to change at page 4, line 39
Client-Cert: The end-entity certificate used by the client in the Client-Cert: The end-entity certificate used by the client in the
TLS handshake with the reverse proxy. TLS handshake with the reverse proxy.
Client-Cert-Chain: The certificate chain used for validation of the Client-Cert-Chain: The certificate chain used for validation of the
end-entity certificate provided by the client in the TLS handshake end-entity certificate provided by the client in the TLS handshake
with the reverse proxy. with the reverse proxy.
2.1. Encoding 2.1. Encoding
The headers in this document encode certificates as Structured Field The headers in this document encode certificates as Byte Sequences
Byte Sequences (Section 3.3.5 of [STRUCTURED-FIELDS]) where the value (Section 3.3.5 of [STRUCTURED-FIELDS]) where the value of the binary
of the binary data is a DER encoded [ITU.X690.1994] X.509 certificate data is a DER encoded [ITU.X690.1994] X.509 certificate [RFC5280].
[RFC5280]. In effect, this means that the binary DER certificate is In effect, this means that the binary DER certificate is encoded
encoded using base64 (without line breaks, spaces, or other using base64 (without line breaks, spaces, or other characters
characters outside the base64 alphabet) and delimited with colons on outside the base64 alphabet) and delimited with colons on either
either side. side.
Note that certificates are often stored encoded in a textual format, Note that certificates are often stored encoded in a textual format,
such as the one described in Section 5.1 of [RFC7468], which is such as the one described in Section 5.1 of [RFC7468], which is
already nearly compatible with a Structured Field Byte Sequence; if already nearly compatible with a Byte Sequence; if so, it will be
so, it will be sufficient to replace "---(BEGIN|END) CERTIFICATE---" sufficient to replace "---(BEGIN|END) CERTIFICATE---" with ":" and
with ":" and remove line breaks in order to generate an appropriate remove line breaks in order to generate an appropriate item.
item.
2.2. Client-Cert HTTP Header Field 2.2. Client-Cert HTTP Header Field
In the context of a TLS terminating reverse proxy deployment, the In the context of a TLS terminating reverse proxy deployment, the
proxy makes the TLS client certificate available to the backend proxy makes the TLS client certificate available to the backend
application with the Client-Cert HTTP header field. This field application with the Client-Cert HTTP header field. This field
contains the end-entity certificate used by the client in the TLS contains the end-entity certificate used by the client in the TLS
handshake. handshake.
Client-Cert is an Item Structured Header [STRUCTURED-FIELDS]. Its Client-Cert is a Byte Sequence with the value of the header encoded
value MUST be a Byte Sequence (Section 3.3.5 of [STRUCTURED-FIELDS]). as described in Section 2.1.
Its ABNF is:
Client-Cert = sf-binary
The value of the header is encoded as described in Section 2.1.
The "Client-Cert" header field is only for use in HTTP requests and The "Client-Cert" header field is only for use in HTTP requests and
MUST NOT be used in HTTP responses. It is a singleton header field MUST NOT be used in HTTP responses. It is a singleton header field
value as defined in Section 5.5 of [HTTP], which MUST NOT have a list value as defined in Section 5.5 of [HTTP], which MUST NOT have a list
of values or occur multiple times in a request. of values or occur multiple times in a request.
Figure 2 in Appendix A has an example of the "Client-Cert" header
field.
2.3. Client-Cert-Chain HTTP Header Field 2.3. Client-Cert-Chain HTTP Header Field
In the context of a TLS terminating reverse proxy deployment, the In the context of a TLS terminating reverse proxy deployment, the
proxy MAY make the certificate chain available to the backend proxy MAY make the certificate chain available to the backend
application with the Client-Cert-Chain HTTP header field. application with the Client-Cert-Chain HTTP header field.
Client-Cert-Chain is a List Structured Header [STRUCTURED-FIELDS]. Client-Cert-Chain is a List (Section 3.3.1 of [STRUCTURED-FIELDS]).
Each item in the list MUST be a Byte Sequence (Section 3.3.5 of Each item in the list MUST be a Byte Sequence encoded as described in
[STRUCTURED-FIELDS]) encoded as described in Section 2.1. The order Section 2.1. The order is the same as the ordering in TLS (such as
is the same as the ordering in TLS (such as described in described in Section 4.4.2 of [TLS]).
Section 4.4.2 of [TLS]).
The header's ABNF is:
Client-Cert-Chain = sf-list
The "Client-Cert-Chain" header field is only for use in HTTP requests The "Client-Cert-Chain" header field is only for use in HTTP requests
and MUST NOT be used in HTTP responses. It MAY have a list of values and MUST NOT be used in HTTP responses. It MAY have a list of values
or occur multiple times in a request. For header compression or occur multiple times in a request. For header compression
purposes, it might be advantageous to split lists into multiple purposes, it might be advantageous to split lists into multiple
instances. instances.
Figure 3 in Appendix A has an example of the "Client-Cert-Chain"
header field.
2.4. Processing Rules 2.4. Processing Rules
This section outlines the applicable processing rules for a TLS This section outlines the applicable processing rules for a TLS
terminating reverse proxy (TTRP) that has negotiated a mutually- terminating reverse proxy (TTRP) that has negotiated a mutually-
authenticated TLS connection to convey the client certificate from authenticated TLS connection to convey the client certificate from
that connection to the backend origin servers. Use of the technique that connection to the backend origin servers. Use of the technique
is to be a configuration or deployment option and the processing is to be a configuration or deployment option and the processing
rules described herein are for servers operating with that option rules described herein are for servers operating with that option
enabled. enabled.
skipping to change at page 7, line 17 skipping to change at page 7, line 12
Forward proxies and other intermediaries MUST NOT add the "Client- Forward proxies and other intermediaries MUST NOT add the "Client-
Cert" or "Client-Cert-Chain" header fields to requests, or modify an Cert" or "Client-Cert-Chain" header fields to requests, or modify an
existing "Client-Cert" or "Client-Cert-Chain" header field. existing "Client-Cert" or "Client-Cert-Chain" header field.
Similarly, clients MUST NOT employ the "Client-Cert" or "Client-Cert- Similarly, clients MUST NOT employ the "Client-Cert" or "Client-Cert-
Chain" header field in requests. Chain" header field in requests.
3. Deployment Considerations 3. Deployment Considerations
3.1. Header Field Compression 3.1. Header Field Compression
If the client certificate header field is generated by an If the connection between the TTRP and origin is capable of field
intermediary on a connection that compresses fields (e.g., using compression (e.g., HPACK [HPACK] or QPACK [QPACK]), and the TTRP
HPACK [HPACK] or QPACK [QPACK]) and more than one client's requests multiplexes more than one client's requests into that connection, the
are multiplexed into that connection, it can reduce compression size and variation of "Client-Cert" and "Client-Cert-Chain" field
efficiency significantly, due to the typical size of the field value values can reduce compression efficiency significantly. An origin
and its variation between clients. Recipients that anticipate could mitigate the efficiency loss by increasing the size of the
connections with these characteristics can mitigate the efficiency dynamic table. If the TTRP determines that the origin dynamic table
loss by increasing the size of the dynamic table. If a recipient is not sufficiently large, it may find it beneficial to always send
does not do so, senders may find it beneficial to always send the the field value as a literal, rather than entering it into the table.
field value as a literal, rather than entering it into the dynamic
table.
3.2. Header Block Size 3.2. Header Block Size
A server in receipt of a larger header block than it is willing to A server in receipt of a larger header block than it is willing to
handle can send an HTTP 431 (Request Header Fields Too Large) status handle can send an HTTP 431 (Request Header Fields Too Large) status
code per Section 5 of [RFC6585]. Due to the typical size of the code per Section 5 of [RFC6585]. Due to the typical size of the
field values containing certificate data, recipients may need to be field values containing certificate data, recipients may need to be
configured to allow for a larger maximum header block size. An configured to allow for a larger maximum header block size. An
intermediary generating client certificate header fields on intermediary generating client certificate header fields on
connections that allow for advertising the maximum acceptable header connections that allow for advertising the maximum acceptable header
skipping to change at page 8, line 45 skipping to change at page 8, line 37
The communication between a TTRP and backend server needs to be The communication between a TTRP and backend server needs to be
secured against eavesdropping and modification by unintended parties. secured against eavesdropping and modification by unintended parties.
The configuration options and request sanitization are necessarily The configuration options and request sanitization are necessarily
functionally of the respective servers. The other requirements can functionally of the respective servers. The other requirements can
be met in a number of ways, which will vary based on specific be met in a number of ways, which will vary based on specific
deployments. The communication between a TTRP and backend or origin deployments. The communication between a TTRP and backend or origin
server, for example, might be authenticated in some way with the server, for example, might be authenticated in some way with the
insertion and consumption of the "Client-Cert" and "Client-Cert- insertion and consumption of the "Client-Cert" and "Client-Cert-
Chain" header fields occurring only on that connection. Chain" header fields occurring only on that connection. Appendix B.3
Alternatively the network topology might dictate a private network of [HTTPSIG] gives one example of this with an application of HTTP
such that the backend application is only able to accept requests Message Signatures. Alternatively the network topology might dictate
from the TTRP and the proxy can only make requests to that server. a private network such that the backend application is only able to
Other deployments that meet the requirements set forth herein are accept requests from the TTRP and the proxy can only make requests to
also possible. that server. Other deployments that meet the requirements set forth
herein are also possible.
5. IANA Considerations 5. IANA Considerations
5.1. HTTP Field Name Registrations 5.1. HTTP Field Name Registrations
Please register the following entries in the "Hypertext Transfer Please register the following entries in the "Hypertext Transfer
Protocol (HTTP) Field Name Registry" defined by HTTP Semantics Protocol (HTTP) Field Name Registry" defined by HTTP Semantics
[HTTP]: [HTTP]:
o Field name: Client-Cert o Field name: Client-Cert
skipping to change at page 10, line 20 skipping to change at page 10, line 11
Nottingham, M. and P-H. Kamp, "Structured Field Values for Nottingham, M. and P-H. Kamp, "Structured Field Values for
HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021, HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,
<https://www.rfc-editor.org/info/rfc8941>. <https://www.rfc-editor.org/info/rfc8941>.
6.2. Informative References 6.2. Informative References
[HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for [HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for
HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
<https://www.rfc-editor.org/info/rfc7541>. <https://www.rfc-editor.org/info/rfc7541>.
[HTTPSIG] Backman, A., Richer, J., and M. Sporny, "HTTP Message
Signatures", draft-ietf-httpbis-message-signatures-13
(work in progress), September 2022.
[QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK: [QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK:
Field Compression for HTTP/3", RFC 9204, Field Compression for HTTP/3", RFC 9204,
DOI 10.17487/RFC9204, June 2022, DOI 10.17487/RFC9204, June 2022,
<https://www.rfc-editor.org/info/rfc9204>. <https://www.rfc-editor.org/info/rfc9204>.
[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", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
skipping to change at page 11, line 39 skipping to change at page 11, line 35
servers-00 servers-00
[2] https://datatracker.ietf.org/meeting/106/materials/minutes- [2] https://datatracker.ietf.org/meeting/106/materials/minutes-
106-secdispatch 106-secdispatch
Appendix A. Example Appendix A. Example
In a hypothetical example where a TLS client presents the client and In a hypothetical example where a TLS client presents the client and
intermediate certificate from Figure 1 when establishing a mutually- intermediate certificate from Figure 1 when establishing a mutually-
authenticated TLS connection with the TTRP, the proxy would send the authenticated TLS connection with the TTRP, the proxy would send the
"Client-Cert" field shown in {#example-header} to the backend. Note "Client-Cert" field shown in Figure 2 to the backend. Note that line
that line breaks and whitespace have been added to the field value in breaks and whitespace have been added to the field value in Figure 2
Figure 2 for display and formatting purposes only. and Figure 3 for display and formatting purposes only.
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQQKDBJMZXQncyBB MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQQKDBJMZXQncyBB
dXRoZW50aWNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBDQTAeFw0yMDAx dXRoZW50aWNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBDQTAeFw0yMDAx
MTQyMjU1MzNaFw0yMTAxMjMyMjU1MzNaMA0xCzAJBgNVBAMMAkJDMFkwEwYHKoZI MTQyMjU1MzNaFw0yMTAxMjMyMjU1MzNaMA0xCzAJBgNVBAMMAkJDMFkwEwYHKoZI
zj0CAQYIKoZIzj0DAQcDQgAE8YnXXfaUgmnMtOXU/IncWalRhebrXmckC8vdgJ1p zj0CAQYIKoZIzj0DAQcDQgAE8YnXXfaUgmnMtOXU/IncWalRhebrXmckC8vdgJ1p
5Be5F/3YC8OthxM4+k1M6aEAEFcGzkJiNy6J84y7uzo9M6NyMHAwCQYDVR0TBAIw 5Be5F/3YC8OthxM4+k1M6aEAEFcGzkJiNy6J84y7uzo9M6NyMHAwCQYDVR0TBAIw
ADAfBgNVHSMEGDAWgBRm3WjLa38lbEYCuiCPct0ZaSED2DAOBgNVHQ8BAf8EBAMC ADAfBgNVHSMEGDAWgBRm3WjLa38lbEYCuiCPct0ZaSED2DAOBgNVHQ8BAf8EBAMC
BsAwEwYDVR0lBAwwCgYIKwYBBQUHAwIwHQYDVR0RAQH/BBMwEYEPYmRjQGV4YW1w BsAwEwYDVR0lBAwwCgYIKwYBBQUHAwIwHQYDVR0RAQH/BBMwEYEPYmRjQGV4YW1w
bGUuY29tMAoGCCqGSM49BAMCA0gAMEUCIBHda/r1vaL6G3VliL4/Di6YK0Q6bMje bGUuY29tMAoGCCqGSM49BAMCA0gAMEUCIBHda/r1vaL6G3VliL4/Di6YK0Q6bMje
skipping to change at page 14, line 9 skipping to change at page 14, line 9
This draft requires that the TTRP sanitize the fields of the incoming This draft requires that the TTRP sanitize the fields of the incoming
request by removing or overwriting any existing instances of the request by removing or overwriting any existing instances of the
"Client-Cert" and "Client-Cert-Chain" header fields before "Client-Cert" and "Client-Cert-Chain" header fields before
dispatching that request to the backend application. Otherwise, a dispatching that request to the backend application. Otherwise, a
client could inject its own values that would appear to the backend client could inject its own values that would appear to the backend
to have come from the TTRP. Although numerous other methods of to have come from the TTRP. Although numerous other methods of
detecting/preventing field injection are possible; such as the use of detecting/preventing field injection are possible; such as the use of
a unique secret value as part of the field name or value or the a unique secret value as part of the field name or value or the
application of a signature, HMAC, or AEAD, there is no common general application of a signature, HMAC, or AEAD, there is no common general
standardized mechanism. The potential problem of client field mechanism. The potential problem of client field injection is not at
injection is not at all unique to the functionality of this draft, all unique to the functionality of this draft, and it would therefore
and it would therefore be inappropriate for this draft to define a be inappropriate for this draft to define a one-off solution. In the
one-off solution. In the absence of a generic standardized solution absence of a generic common solution existing currently, stripping/
existing currently, stripping/sanitizing the fields is the de facto sanitizing the fields is the de facto means of protecting against
means of protecting against field injection in practice today. field injection in practice. Sanitizing the fields is sufficient
Sanitizing the fields is sufficient when properly implemented and is when properly implemented and is a normative requirement of
a normative requirement of Section 4. Section 4.
B.2. The Forwarded HTTP Extension B.2. The Forwarded HTTP Extension
The "Forwarded" HTTP header field defined in [RFC7239] allows proxy The "Forwarded" HTTP header field defined in [RFC7239] allows proxy
components to disclose information lost in the proxying process. The components to disclose information lost in the proxying process. The
TLS client certificate information of concern to this draft could TLS client certificate information of concern to this draft could
have been communicated with an extension parameter to the "Forwarded" have been communicated with an extension parameter to the "Forwarded"
field; however, doing so would have had some disadvantages that this field; however, doing so would have had some disadvantages that this
draft endeavored to avoid. The "Forwarded" field syntax allows for draft endeavored to avoid. The "Forwarded" field syntax allows for
information about a full chain of proxied HTTP requests, whereas the information about a full chain of proxied HTTP requests, whereas the
skipping to change at page 15, line 40 skipping to change at page 15, line 40
o Torsten Lodderstedt o Torsten Lodderstedt
o Kathleen Moriarty o Kathleen Moriarty
o Mark Nottingham o Mark Nottingham
o Erik Nygren o Erik Nygren
o Mike Ounsworth o Mike Ounsworth
o Lucas Pardue
o Matt Peterson o Matt Peterson
o Eric Rescorla o Eric Rescorla
o Justin Richer o Justin Richer
o Michael Richardson o Michael Richardson
o Joe Salowey o Joe Salowey
o Rich Salz o Rich Salz
o Mohit Sethi o Mohit Sethi
o Rifaat Shekh-Yusef o Rifaat Shekh-Yusef
o Travis Spencer o Travis Spencer
o Nick Sullivan o Nick Sullivan
o Willy Tarreau o Willy Tarreau
 End of changes. 21 change blocks. 
78 lines changed or deleted 82 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/