One document matched: draft-mcgrew-tls-proxy-server-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC4366 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4366.xml">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC2818 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml">
<!ENTITY RFC2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-mcgrew-tls-proxy-server-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="TLS Proxy Server">TLS Proxy Server Extension</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="David A. McGrew" initials="D.A.M." surname="McGrew">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>510 McCarthy Blvd.</street>
<city>Milpitas</city>
<region>CA</region>
<code>95035</code>
<country>US</country>
</postal>
<phone>(408) 525 8651</phone>
<email>mcgrew@cisco.com</email>
<uri>http://www.mindspring.com/~dmcgrew/dam.htm</uri>
</address>
</author>
<author fullname="Philip Gladstone" initials="P.J.S.G."
surname="Gladstone">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>1414 Mass Ave</street>
<!-- Reorder these if your country does things differently -->
<city>Boxborough</city>
<region>MA</region>
<code>01719</code>
<country>US</country>
</postal>
<email>pgladstone@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="July" year="2011" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>TLS, Proxy</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>Transport Layer Security (TLS) is commonly used to protect HTTP and
other protocols. HTTP is often proxied, for instance, to allow an
application-layer firewall to inspect the HTTP traffic between the
client and the server. A TLS session cannot protect traffic between the
client and server when an HTTP proxy is present. Separate TLS sessions
can be run between the client and the proxy, on one side, and the proxy
and the server on the other side. This provides the needed security, as
long as the client, server, and proxy device use appropriate and
consistent security policies. However, this last part is problematic;
how can a proxy know if a client trusts a server? At present, TLS
provides no mechanism to coordinate policies.</t>
<t>This note defines a TLS extension that allows a TLS proxy to provide
a TLS client with all of information about the TLS server that the
client needs to make a well-informed access control decision.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Transport Layer Security (TLS) <xref target="RFC5246">RFC 5246</xref>
is commonly used to protect HTTP <xref target="RFC2616"></xref> as
described in <xref target="RFC2818"></xref>. In many scenarios an HTTP
proxy is used, for instance, to allow caching, to provide anonymity to a
client, or to provide security by using an application-layer firewall to
inspect the HTTP traffic on behalf of the client. A TLS session cannot
protect traffic between the client and server when a proxy is present.
It is possible to have separate TLS sessions between the client and the
proxy, on one side, and the proxy and the server on the other side, as
show in <xref target="simple"></xref> . This technique provides the
appropriate cryptographic security (see below for a discussion of why
some other alternatives are less attractive). But there is a problem:
the presence of the proxy removes the client's knowledge about the
server. Without this knowledge, the client has no way to decide what
trust, if any, it should have in the server. This is most problematic
when the client trusts multiple different servers for different
applications, or trusts servers from different domains. </t>
<t><figure align="center" anchor="simple">
<artwork align="left"><![CDATA[
Client Proxy Server
TLS Session #1 TLS Session #2
<------------> <------------->
HTTP
<----------------------------------->
]]></artwork>
<postamble>A proxied HTTPS session, with two independent TLS
sessions. </postamble>
</figure></t>
<t>A further issue is that the client cannot determine the security
level of the TLS session between the proxy and the server. For instance,
a client can negotiate a high security ciphersuite between itself and
the proxy, but it will have no way of knowing what ciphersuite is in use
between the client and the server, which could be using the obsolete
56-bit Data Encryption Standard (DES) cipher.</t>
<t>Another point of difficulty is the fact that there can be multiple
proxies on a particular path. To solve the security issues introduced by
TLS proxies in a way that is generally applicable, it is necessary to
accommodate scenarios involving multiple proxies. </t>
<t>We propose a solution in this note, by describing a TLS extension
that can be used by a proxy to provide information to a TLS client about
the TLS server. When this extension is used, the client is well informed
about the proxy as well as the server, and can make a knowledgeable
access control decision about the server, using the same processes that
it uses when the proxy is not present. The data in the extension are
signed by the proxy in order to bind the information about the server to
a particular session between the client and the proxy. When there are
multiple proxies, the client is informed about all of them. This
extension also works for DTLS. </t>
<t>A separate issue is the provisioning of the proxy with information
about what servers (or rather, which certificates) should be trusted. If
the laptop has installed certificates that are specific to its
organization or to a particular domain, how can the proxy know to trust
these certificates on behalf of the laptop? </t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="Motivation">
<t>The following motivating example describes a typical situation with a
TLS proxy, as in <xref target="simple"></xref>. A laptop trusts the
server A for a particular banking application, and trusts server B for a
social media application, and can authenticate both servers by using
standard PKIX certificate checking <xref target="RFC5280"></xref> and
locally stored root certificates. Or rather, the client trusts a set of
root certificates, and uses them to authenticate the TLS servers that it
connects with. The laptop also trusts the proxy, and has a certificate
by which it can authenticate the proxy. When making a connection
directly with B, the laptop can authenticate the server as being trusted
(that is, the server's public key appears in a certificate that has been
signed by the appropriate trusted certificate authority), and it can
also check the authorizations of that server (that is, B is authorized
to provide the social media service, but not any other services such as
banking). If the web traffic from the laptop goes through an HTTP proxy,
then the proxy will need to know that it should trust both A and B to
act as TLS servers. Assuming that it does have this knowledge, it will
proxy TLS connections from both A and B. However, when the client
attempts to establish an HTTPS connection to A through the proxy, it has
no way of knowing what security checks the proxy has applied to the
connection between the proxy and A. The client cannot tell whether the
trusted certificate that it associates with A was used on the connection
between the proxy and A. The inability of the client to be confident of
the identity of the actual server forces the client to trust all TLS
servers indiscriminately.</t>
<t>This obstacle could be overcome by pushing the client's policy (that
is, information about what servers it trusts for what applications) onto
the proxy, so that the proxy can make well-informed decisions on behalf
of the client. However, this alternative has significant drawbacks: it
requires that the proxy obtain and store a significant amount of
information about each client, and it requires the construction of a
syntax by which the client's policy can be expressed and understood. In
contrast, our solution moves the information about the server to the
client, which does not require the communication or storage of any
security policy between the client and server.</t>
<t></t>
</section>
<section anchor="intro" title="Operation">
<t>In this note, a TLS proxy is a device that acts as a TLS server in
one session and acts as a TLS client in another session, and passes all
of the data from one session to the other, possibly modifying it in the
process. That is, it is a non-transparent proxy, in the terms of <xref
target="RFC2616"></xref>. </t>
<figure align="center" anchor="basic">
<artwork align="left"><![CDATA[
TLS Session #1 TLS Session #2
Client <------------> Proxy <-------------> Server
Session #1 Session #2 Session #3
Client <---------> Proxy #1 <--------> Proxy #2 <---------> Server
]]></artwork>
<postamble>A TLS session with a single proxy (top) and a TLS session
with two proxies (bottom).</postamble>
</figure>
<t>The essential idea is as follows. When a TLS proxy is contacted by a
client, it does not respond to the client until it completes a TLS
session with the server. It then sends the client an assertion about the
server and the session, signed with the same private key that it uses in
its role as the TLS proxy server. When the client receives this
assertion, it checks the data in the assertion to determine whether or
not it trusts the server. The assertion is carried in a
ProxyInfoExtension, which is defined below.</t>
<t>This extension carries all of the information that is available to a
TLS client about a TLS server; thus the client can use existing
authorization checking processes. The client will need to verify the
hostname and/or address, and check to see if the certificate has been
revoked. The client authenticates the proxy server as usual during the
TLS session. This ensures that the client trusts the proxy, and because
of the signature on the assertion, it should trust the server
certificate carried in the assertion. The proxy need not perform any
checking on the server certificate, because this check is done by the
client. Of course, by completing a TLS exchange with the server, the
proxy verifies that the server holds the private key associated with
that certificate.</t>
<t><!--We have assumed that the proxies are acting in transparent mode i.e. they are trying to establish a connection to the same server as the client specifies. Are there other proxies that might not have this characteristic, and how do we want to deal with them?-->It
is required that proxies which implement this extension and support TLS
Session Resumption handle TLS Session Resumptions (from the client) by
requiring TLS Session Resumption with the server. In particular, a TLS
session that is resumed with a client SHOULD correspond to the proxy
successfully resuming the TLS session with the same server. When a
client resumes a session with a proxy, the proxy SHOULD attempt to
resume the corresponding session with the server. </t>
<t>Because there may be more than one proxy in any path, the TLS
extension carries a list of assertions.</t>
<t>On receiving a ClientHello from the client, the proxy:<list
style="numbers">
<t>Checks for a ProxyInfoExtension in the ClientHello; if there is
no such extension, then the following steps cannot be performed and
are omitted,</t>
<t>Establishes a TLS session with the server (session #2 in <xref
target="simple"></xref>); a ProxyInfoExtension is included in that
session,</t>
<t>Constructs a ProxyInfo structure by populating it with
information about the server and the current session with that
server; if the sever sends back a ProxyInfoExtension, then the
ProxyInfo structure is included as the next_proxy_info,</t>
<t>Signs the ProxyInfo structure with the public key corresponding
to the server certificate it uses in session #1, </t>
<t>Completes the session with the client (session #1 in <xref
target="simple"></xref>) and provides the ProxyInfoExtension in that
session,</t>
</list></t>
<t>The proxy MAY <list style="empty">
<t>Perform revocation checking on the certificate chain of the
server in session #2, and indicate that it has done this in the
extension by setting performed_revocation_checking to "true".</t>
</list></t>
<t>Note that the entity acting in the role of the server in session #2
could be a proxy, but in the above it is referred to as a server because
that is the role that it performs in that TLS session. </t>
<t>When TLS is used in HTTPS, the proxy MUST perform the Server Identity
checks described in Section 3.1 of <xref target="RFC2818"></xref>.</t>
<t>The normal operation of the proxy is to accept the (extended)
ClientHello from the client and then send a ClientHello to the server.
It is recommended that the TLS Proxy support commonly deployed TLS
extensions (as defined in <xref target="RFC4366"></xref> et al). Any TLS
extensions present on the original ClientHello MUST be examined and
either ignored, processed or forwarded (possibly after modification) to
the TLS server as part of the new ClientHello.</t>
<t>The client:</t>
<t><list style="numbers">
<t>Includes a ProxyInfoExtension in the ClientHello message, </t>
<t>Checks for ProxyInfoExtension in the ServerHello message; if
there is no such extension, then the TLS processing continues as
usual; otherwise, </t>
<t>Processes the ProxyInfo extension by checking the validity of the
digitally-signed struct, then performing the usual server
authentication and authorization checking on the
server_certificate_list in the ProxyInfo,</t>
<t>Checks the revocation_checking_performed flag in the ProxyInfo;
if it is "false", then the client SHOULD perform revocation checking
on the server_certificate_list, </t>
<t>Checks the ProxyInfoFlag in the next_proxy_info field; if it is
not_empty, then the client returns to step 3 and performs that
processing on the next_proxy_info. </t>
</list></t>
<t>In order to maintain backwards compatibility for existing TLS
clients, the TLS proxies MUST (by default) perform certificate
validation for the certificates that they receive from the server. The
use of the ProxyInfoExtension in the extended ClientHello is an
indication by the client to request the alternate processing defined by
this note. In particular, if this extension is present in the extended
ClientHello, then the TLS proxy should not use its own private key to
dynamically generate a certificate.</t>
<t>The proxy will relay the data between the client and peer data
connections. End-to-end flow control is maintained by the relay process:
if the relay process is no longer able to write data to the destination
of the relayed data, the relay process stops reading data from the
source.</t>
<section title="ProxyInfoExtension">
<t>The syntax of the ProxyInfo extension is as follows<figure>
<artwork><![CDATA[struct {
PRFAlgorithm prf_algorithm;
BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type;
uint8 enc_key_length;
uint8 block_length;
uint8 fixed_iv_length;
uint8 record_iv_length;
MACAlgorithm mac_algorithm;
uint8 mac_length;
uint8 mac_key_length;
CompressionMethod compression_algorithm;
} ConnectionSecurityParameters;
enum { empty, not_empty } ProxyInfoFlag;
struct {
select (ProxyInfoFlag) {
case empty:
/* zero length body */
case not_empty:
digitally-signed struct {
ConnectionSecurityParameters connection_parameters;
ASN.1Cert server_certificate_list<0..2^8-1>;
Boolean revocation_checking_performed;
ProxyInfo next_proxy_info;
} SignedProxyInfo;
}
} ProxyInfo;
struct {
ProxyInfo proxy_info;
} ProxyInfoExtension;
]]></artwork>
<postamble>In this extension, .</postamble>
</figure></t>
<t>The ProxyInfo structure is defined recursively, so that the
signature of each proxy authenticates the information provided by the
proxies that follow it on the path. The ProxyInfo contains the
ProxyInfoFlag, which indicates whether or not the ProxyInfo is empty
(in which case it contains no other fields) or not (in which case it
contains a SignedProxyInfo structure). The SignedProxyInfo structure
is signed with the public key that the proxy uses in its role as the
TLS server (in session #1). That structure contains the
connection_parameters that describe the security of session #2, and
the certificate chain of the server from session #2 in the
server_certificate_list. If the proxy has performed revocation
checking on that certificate chain, it indicates this by setting the
Boolean revocation_checking_performed. If the server in session #2 was
actually a proxy itself, and it provides a ProxyInfo struct, then that
struct is included in the next_proxy_info field. Otherwise, the
next_proxy_info field contains an empty ProxyInfo. </t>
<t><!--Note that there is an optimization where the proxy can check to see if the original last ProxyCertificateInfo element contains the same certificate as the current server certificate. If these certificates are the same, then the original last ProxyCertificateInfo element is adjusted to trucate the my_certificate_list field. This optimization will normally halve the size of the Extension for long chains of proxies--></t>
<t><figure>
<artwork><![CDATA[
enum {
/* ... */
proxy_info(TBD1), (65535)
} ExtensionType;
]]></artwork>
</figure></t>
</section>
<section title="ProxyInfoExtension">
<t></t>
</section>
</section>
<section title="Discussion">
<t>The ProxyInfo extension could contain information about the checking
that the proxy performed on the server and its certificate. For example,
if the DNS name of the server matched the subjectAltName, this fact
could be indicated. It may be desirable to enumerate the ways in which
the server can match its certificate, to allow the proxy to indicate to
the client which of those ways was positive for a particular server.</t>
<t>A potential issue with the ProxyInfo extension is that it can be
large, because the certificate chains that it carries can be large.
Roughly speaking, the amount of certificate data presented to the client
is proportional to the number of proxies on the path. It is undesirable
to require that so much data be sent, but on the other hand, the client
does need all of the data in order to make a well-informed access
control decision. It appears that the data is the minimum required, in
the sense that removing any of the data would make it impossible for the
client to assess the security of the entire path. </t>
<t>The proxy is required to do the authentication checking on the
signatures created by the server, but not the authorization checking or
revocation checking. The responsibility for authorization checking is
not put onto the proxy because it does not know the security policy of
the client; in particular, the proxy does not know which servers the
client trusts for which applications. The responsibility for revocation
checking is not put onto the proxy because that process is better left
to the client. The client can perform revocation checking on all of the
certificate lists for all of the proxies and the server in parallel,
whereas if each proxy performed the revocation checking, those processes
would necessarily be serial. Since revocation checking can take a
significant amount of time, the serial approach could add a significant
amount of latency to the TLS session, and potentially trigger
retransmissions. The parallel approach not only reduces the overall
latency, but it moves it outside of the client's retransmission timer
for the ClientHello message. </t>
<t><!--If this is problematic, it can be avoided by having the extension carry only the essential fields from the certificate. But that would make the implementation a bit more complex, and would require ASN.1 tinkering, which IMO should be avoided if possible. It is also not clear that we could define which fields could be omitted from the certificate.-->The
ProxyInfo extension could convey the IP address of the server, or other
network layer information such as the DNS name. However, it is not clear
that this information is needed, so it was not included.</t>
<t>The ProxyInfo extension only provides information about proxies to
the client; it does not provide any information to the server about
either the client or other proxies on the path. This is acceptable when
there are no client certificates in use, which is (regrettably) common
in practice. It would be possible to generalize the ideas in this note
to also provide information to the server about the client and other
proxies on the path. Nonetheless, that goal is out of scope for this
note. </t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document requests IANA to update its registry of TLS extension
types to assign an entry, referred herein as proxy_info, with the number
TBD1. </t>
</section>
<section anchor="Security" title="Security Considerations">
<t>In a situation with a proxy and a cryptographic protocol, the
appropriate security goals are to</t>
<t><list>
<t>preserve the security of the cryptographic protocol, </t>
<t>make the client aware of the proxy, able to authenticate the
proxy, and able to check that the device acting as a proxy is
authorized to act in that role,</t>
<t>allow the client to make access control decisions that are as
well-informed as when the proxy is not present.</t>
</list>The idea in this note meets these goals.</t>
<t>We briefly describe some alternative approaches that do not meet
these security goals. First, we consider the proliferation of private
keys. In order to allow one device to act as a proxy for a server, the
private key of the server could be shared with the proxy. This practice
may be workable when there is a one-to-one correspondence between
proxies and servers, but it substantially increases the security risk.
If a proxy contains multiple private keys, it becomes an attractive
target for an attacker. Second, we consider the session-key
proliferation approach in which there is only a single TLS session,
negotiated between the client and server, and the proxy participates in
the session because either the client or the server has passed the
secret session keys to the proxy (using some secure channel). If the
proxy is completely passive, and it only decrypts traffic from the TLS
session and never modifies the data in that session, then this method
can be secure. However, if the proxy rewrites the data inside the
session, or originates messages, then the security of the TLS protocol
will be undermined. Message authentication can be subverted because an
attacker can intercept a message sent by the server, and forward it on
to the client, bypassing the proxy. By interleaving messages sent by the
proxy with ones sent by the server, an attacker can potentially confuse
a client, and can certainly cause a denial of service. Confidentiality
may be undermined as well; if RC4 or AES-GCM is in use, information
about the plaintext will be leaked due to keystream reuse. Session-key
proliferation is not secure when the proxy needs to edit the session.
Most proxies do need to edit the session, and we regard it as
potentially hazardous to construct a TLS proxy along these lines.
Suppose that such a proxy were implemented because it was anticipated
that the application proxy would be read-only, but then a future
revision to the application protocol or the goals of the application
proxy made it necessary to have the proxy edit the application session.
If the session-key proliferation approach had been used, the implementer
would be in the awkward position of having to choose between
implementing a completely new approach that preserved security, and in
risking the security of the application. </t>
<t>With the ProxyInfo extension, there is no protection against the
proxy lying about the security characteristics of the onward connection.
However, in any proxying scenario, it is necessary to trust the proxy,
just as a client must trust the server. For instance, any proxy (not
just one using the ProxyInfo extension) could choose to forward the
plaintext from the session to untrusted third parties, and violate the
trust of the client. It is the responsibility of the client to decide
whether or not a particular device should be trusted to act in the role
of proxy. The ProxyInfo proposal has the benefit of making the presence
of the proxy obvious, and allows the client to refuse to deal with
untrusted proxies.</t>
<t><!--Adoption of this proposal will allow TLS clients to become stricter about the certificates that they accept, as they do not have to permit the presence of proxies that generate fake certificates -->Many
clients use password-based authentication within a TLS tunnel. When a
proxy is present, it can learn plaintext passwords, and it can gain the
information needed to perform offline dictionary attacks against
authentication systems that use challenge-response methods. This is a
highly undesirable aspect of TLS proxying. The ProxyInfo extension does
nothing to directly help this issue. However, it does indirectly improve
the situation, because it empowers the client with information that
enables it to reject proxies and servers that it should not trust. Since
the TLS authentication (including both sever and proxy authentication)
takes place before the password-based authentication, the client can
protect itself by rejecting sessions with inappropriate proxies, or
inappropriate servers on the path beyond the proxy. </t>
<t>In theory, the cryptographic proxying scenario could be considered as
multiparty security negotiation and key establishment. It may be
interesting to investigate such ideas because they can allow for more
equitable negotiation of session parameters, and additional security
properties. This note focuses on compatibility with existing
specifications and implementations, so these considerations are beyond
its scope. </t>
</section>
<section title="Acknowledgements">
<t>
Thanks are due to Dan Wing for suggestions and fruitful discussion.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml"?-->
&RFC5246;
&RFC2119;
&RFC5280;
&RFC2818;
&RFC4366;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<!-- A reference written by by an organization not a person. -->
&RFC2616;
</references>
<!-- Change Log
v00 2006-03-15 EBD Initial version
v01 2006-04-03 EBD Moved PI location back to position 1 -
v3.1 of XMLmind is better with them at this location.
v02 2007-03-07 AH removed extraneous nested_list attribute,
other minor corrections
v03 2007-03-09 EBD Added comments on null IANA sections and fixed heading capitalization.
Modified comments around figure to reflect non-implementation of
figure indent control. Put in reference using anchor="DOMINATION".
Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH Major changes: shortened discussion of PIs,
added discussion of rfc include.
v05 2007-03-10 EBD Added preamble to C program example to tell about ABNF and alternative
images. Removed meta-characters from comments (causes problems). -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:29:12 |