One document matched: draft-hartman-emu-mutual-crypto-bind-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="info" docName="draft-hartman-emu-mutual-crypto-bind-00.txt"
ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="Mutual Crypto Binding">EAP Mutual Cryptographic
Binding</title>
<author fullname="Sam Hartman" initials="S." surname="Hartman">
<organization>Painless Security</organization>
<address>
<email>hartmans-ietf@mit.edu</email>
</address>
</author>
<author fullname="Margaret Wasserman" initials="M." surname="Wasserman">
<organization>Painless Security</organization>
<address>
<email>mrw@painless-security.com</email>
<uri>http://www.painless-security.com/</uri>
</address>
</author>
<author fullname="Dacheng Zhang" initials="D." surname="Zhang">
<organization>Huawei</organization>
<address>
<email>zhangdacheng@huawei.com</email>
</address>
</author>
<date />
<abstract>
<t>As the Extensible Authentication Protocol (EAP) evolves, EAP peers
rely increasingly on information received from the EAP server. EAP
extensions such as channel binding or network posture information are
often carried in tunnel methods; peers are likely to rely on this
information. [RFC 3748] is a facility that protects tunnel methods
against man-in-the-middle attacks. However, cryptographic binding
focuses on protecting the server rather than the peer. This memo
explores attacks possible when the peer is not protected from
man-in-the-middle attacks and recommends mutual cryptographic binding, a
new form of cryptographic binding that protects both peer and
server.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The Extensible Authentication Protocol <xref target="RFC3778"></xref>
provides authentication between a peer (a party accessing some service)
and a authentication server. Traditionally, peers have not relied
significantly on information received from EAP servers. However
facilities such as EAP Channel Binding <xref
target="I-D.ietf-emu-chbind"></xref> provide the peer with confirmation
of information about the resource it is accessing. Other facilities such
as EAP Posture Transport <xref target="I-D.ietf-nea-pt-eap"></xref>
permit a peer and EAP server to discuss the security properties of
accessed networks. Both of these facilities provide peers with
information they need to rely on and provide attackers who are able to
impersonate an EAP server to a peer with new opportunities for
attack.</t>
<t>Instead of adding these new facilities to all EAP methods, work has
focused on adding support to tunnel methods <xref
target="I-D.ietf-emu-eaptunnel-req"></xref>. There are numerous tunnel
methods including <xref target="RFC4851"></xref>, <xref
target="RFC5281"></xref>, and work on building a standards track tunnel
method <xref target="I-D.ietf-emu-eap-tunnel-method"></xref>. These
tunnel methods are extensible. By adding an extension to support a
facility such as channel binding to a tunnel method, it can be used with
any inner method carried in the tunnel.</t>
<t>Tunnel methods need to be careful about man-in-the-middle attacks.
See section 3.2 and 4.6.3 in <xref
target="I-D.ietf-emu-eaptunnel-req"></xref> and <xref
target="TUNNEL-MITM"></xref> for a detailed description of these
attacks. An example of the attack can happen when a peer is willing to
perform authentication inside and outside a tunnel. An attacker can
impersonate the EAP server and offer the inner method to the peer.
However, on the other side, the attacker acts as a man-in-the-middle and
opens a tunnel to the real EAP server. Figure 1 illustrates this attack.
At the end of the attack, the EAP server believes it is talking to the
peer. At the inner method level, this is true. At the outer method
level, however, the server is talking to the attacker.</t>
<figure title="Classic Tunnel Attack">
<artwork><![CDATA[ Please view in a fixed-width font such as Courier.
Client Attacker Server Auth Server
| | | |
| | | |
| | Tunnel establishment |
| | Server Authentication |
| |<================================>|
| | | |
| (Non-Authenticated | (Authenticated
| end of tunnel) | end of tunnel)
| | | |
| +--------------+ | +--------------+
| | Tunnel | | | Tunnel |
| | Keys Derived | | | Keys Derived |
| +--------------+ | +--------------+
| |..................................|
| | Tunnel |
| | | |
| | (Encrypted using Tunnel keys) |
| Inner | | |
| authentication | | |
| method | Tunneled authentication method |
|<===================>|<================================>|
| | | |
| |..................................|
| | | |
| | |<==tunnel keys==|
| | Client's session| |
| | stolen | |
| |<===============>| |
]]></artwork>
<postamble>A classic tunnel attack where the attacker inserts an extra
tunnel between the attacker and EAP server.</postamble>
</figure>
<t>There are several mitigation strategies for this classic attack.
First, security policy can be set up so that the same method is not
offered by a server both inside and outside a tunnel. A technical
solution is available if the inner method is sufficiently strong.
Cryptographic binding is a security property of a tunnel method under
which the EAP server confirms that the inner and outer parties are the
same. One common way to do this is to ask the outer party (the other end
of the tunnel) to prove knowledge of the Master Session Key (MSK) of the
inner method. As defined in RFC 3748, cryptographic binding may prove to
the peer that the inner and outer exchanges are with the same party, but
it typically does not make this proof; instead it is typically
limited to proving to the server that the inner and outer peer
are the same.</t>
</section>
<section title="An Example Problem">
<t>The GSS-EAP mechanism <xref target="I-D.ietf-abfab-gss-eap"></xref>
provides application authentication using EAP. A peer could reasonably
trust some applications significantly more than others. If the peer
sends confidential information to some applications, an attacker may
gain significant value from convincing the peer that the attacker is the
trusted application. Channel bindings are used to tell the peer which
application service is being connected to. Prior to channel bindings,
peers could not distinguish one Network Access Service (NAS) from
another, so attacks where one NAS impersonated another were
out-of-scope. However channel bindings add this capability and thus
expands the threat model of EAP. The GSS-EAP mechanism requires distinguishing
one service from another.</t>
<t>A relatively untrusted service, say a print server, has been
compromised. A user is attempting to connect to a trusted service such
as a financial application. Both the print server and the financial
application use an Authentication, Authorization and Accounting protocol
(AAA) to transport EAP authentication back to the user's EAP server. The
print server mounts a man-in-the-middle attack on the user's connection
to the financial application and claims to be the application.</t>
<t>The print server offers a tunnel method towards the peer. The print
server extracts the inner method from the tunnel and sends it on towards
the AAA server. Channel binding happens at the tunnel method though. So,
the print server is happy to confirm that it is the financial
application. After the inner method completes, the EAP server sends the
MSK to the print server over the AAA protocol. If only the MSK is needed
for cryptographic binding then the print server can successfully perform
cryptographic binding and may be able to impersonate the
financial application to the peer.</t>
<figure title="Channel Binding Requires More than Crypto Binding">
<artwork><![CDATA[ Please view in a fixed-width font such as Courier.
Client Attacker Server Auth Server
| | | |
| | | |
| Tunnel establishment| | |
| | | |
|<===================>| | |
|.....................| | |
| Tunnel | | |
| | | |
| (Encrypted using | | |
| Tunnel keys) | | |
| | | |
| Tunneled | | |
| authentication | | |
| method | Inner authentication method |
|<===================>|<================================>|
|.....................| | |
| |<=====MSK keys====================|
| Client's session | | |
| stolen | | |
|<===================>| | |
]]></artwork>
<postamble>A modified tunnel attack when an extra server rather than
extra client is inserted.</postamble>
</figure>
<t>This attack is not specific to GSS-EAP. The channel bindings
specification <xref target="I-D.ietf-emu-chbind"></xref> describes a
number of situations where channel bindings are important for network
access. In these situations one NAS could impersonate another by using a
similar attack.</t>
</section>
<section title="The Server insertion Attack">
<t>The previous section described an example of the server insertion
attack. In this attack, one party adds a layer of tunneling such that
from the perspective of the EAP peer, there are more methods than from
the perspective of the EAP server. This attack is most beneficial when
the party inserting the extra tunnel is a legitimate NAS, so mitigations
need to be able to prevent a legitimate NAS from inappropriately adding
a layer of tunneling. Some deployments utilize an intentional
intermediary that adds an extra level of EAP tunneling between the peer
and the EAP server; see <xref target="GOODMITM"></xref> for a
discussion.</t>
<section title="Conditions for the Attack">
<t>For an inserted server attack to have value, the attacker needs to
gain an advantage from its attack. An advantage to the attacker could
come from: <list style="symbols">
<t>The attacker can send information to a peer that the peer would
trust from the EAP server but not the attacker. Examples of this
include channel binding responses.<vspace /></t>
<t>The peer sending information to the attacker that was intended
for the EAP server. For example, the inner user identity may
disclose privacy-sensitive information. The channel binding
request may disclose what service the peer wishes to connect
to.<vspace /></t>
<t>The attacker may influence session parameters. For example, if
the attacker can influence the MSK, then the attacker may be able
to read or influence session traffic and mount an attack
on the confidentiality or integrity of the resulting session.<vspace /></t>
<t>An attacker may impact availability of the session. In practice
though, an attacker that can mount a server insertion attack is
likely to be able to impact availability in other
ways.<vspace /></t>
</list></t>
<t>For this attack to be possible, the following conditions need to
hold: <list style="numbers">
<t>The attacker needs to be able to establish a tunnel method with
the peer over which the peer will authenticate.<vspace /></t>
<t>The attacker needs to be able to respond to any inner
authentication. For example an attacker who is a legitimate NAS
can forward the inner authentication over AAA towards the EAP
server. Note that the inner authentication may not be
EAP.<vspace /></t>
<t>Typically, the attacker needs to be able to complete the tunnel
method after inner authentication. This may not be necessary if
the attacker is gaining advantage from information sent by the
peer over the tunnel.<vspace /></t>
<t>In some cases the attacker may need to complete a Secure
Association Protocol (SAP) or otherwise demonstrate knowledge of
the MSK after the tunnel method successfully
completes.<vspace /></t>
</list></t>
<t>Attackers who are legitimate NASes are the primary focus of this
memo. Previous work has provided mitigation against attackers who are
not a NAS; these mitigations are briefly discussed.</t>
</section>
<section title="Mitigation Strategies">
<section title="Server Authentication">
<t>If the peer confirms the identity of the party that the tunnel
method is established with, the peer prevents the first condition
(attacker establishing a tunnel method). Many tunnel methods rely on
TLS <xref target="RFC5281"></xref> <xref
target="I-D.ietf-emu-eap-tunnel-method"></xref>. The specifications
for these methods tend to encourage or mandate certificate checking.
If the TLS certificate is validated back to a trust anchor and the
identity of the tunnel method server confirmed, then the first
attack condition cannot be met.</t>
<t>Many challenges make server authentication difficult. There is
not an obvious name by which to identify a tunnel method server. It
is not obvious where in the tunnel server certificate the name
should be found. One particularly problematic practice is to use a
certificate that names the host on which the tunnel server runs.
Given such a name it is very difficult for a peer to understand
whether that server is intended to be a tunnel method server for the
realm.</t>
<t>It's not clear what trust anchors to use for tunnel servers.
Using commercial Certificate Authorities (CAs) is probably
undesirable because tunnel servers often operate in a closed
community and are often provisioned with certificates issued by that
community. Using commercial CAs can be particularly problematic with
peers that support hostnames in certificates. Then anyone who can
obtain a certificate for any host in the domain being contacted can
impersonate a tunnel server.</t>
<t>These difficulties lead to poor deployment of good certificate
validation. Many peers make it easy to disable certificate validation.
Other peers validate back to trust anchors but do not check
names of certificates. What name types are supported and
what configuration is easy to perform depends significantly
on the peer in question.</t>
<t>Specifications also make the problem worse. For example <xref
target="RFC5281"></xref> indicates that the only impact of failing
to perform certificate validation is that the inner method can be
attacked. Administrators and implementors believing this claim may
believe that protection from passive attacks is sufficient.</t>
<t>In addition, some deployments such as provisioning or strong
inner methods are designed to work without certificate validation.
Section 3.9 of the tunnel requirements <xref
target="I-D.ietf-emu-eaptunnel-req"></xref> discusses this
requirement.</t>
</section>
<section title="Server Policy">
<t>Server policy can potentially prevent the second
condition (attacker being able to respond to inner
authentication) from being possible. If the server only
performs a particular inner authentication within a tunnel,
then the attacker cannot gain a response to the inner
authentication without their being such a tunnel. The
attacker may be able to add a second layer of tunnels; see
<xref target="FIG.MULTI-TUNNEL"/>. The inner tunnel may
limit the attacker's capabilities; for example if channel
binding is performed over tunnel t2 in the figure, then an
attacker cannot observe or influence it.</t>
<figure anchor="FIG.MULTI-TUNNEL" title="Multiple Layered
Tunnels">
<artwork></artwork>
<postamble>A tunnel t1 from the peer to the attacker
contains a tunnel t2 from the peer to the home EAP
server. Inside t2 is an inner authentication.</postamble>
</figure>
<t>Peer policy can be combined with this server policy to
help prevent conditions 1 (attacker can establish a tunnel
the peer will use) and 2 (attacker can respond to inner
authentication). If the peer requires exactly one tunnel of
a particular type and the EAP server only performs inner
authentication over a tunnel of this type, then the attacker
cannot establish tunnel t1 in the figure above.</t>
<t>An attacker may be able to mount a more traditional
man-in-the-middle attack in this instance; see <xref
target="FIG.MITM"/>. This policy on the peer and EAP server
combined with a tunnel method that supports cryptographic
binding will allow the EAP server to detect the
attacker. This means the attacker cannot act as a legitimate
NAS and in particular does not obtain the MSK. So, if the
tunnel between the attacker and peer also requires
cryptographic binding and if the cryptographic binding
requires both the EAP server and peer to prove knowledge of
the inner MSK, then the authentication will fail.</t>
<figure anchor="FIG.MITM" title="A Traditional
Man-in-the-Middle Attack">
<artwork></artwork>
<postamble>A tunnel t1 extends from the peer to the
attacker. a tunnel t2 extends from the attacker to the
home EAP server. An inner EAP authentication is forwarded
unmodified by the attacker from t1 to t2. The attacker can
observe this inner authentication.</postamble>
</figure>
<t>Cryptographic binding is only a valuable component of a
defense if the inner authentication is a key-deriving EAP
method. Most tunnel methods also support non-EAP inner
authentication such as Microsoft Chap version 2 <xref
target="RFC2759"/>. This may undermine cryptographic binding
in a number of ways. An attacker may be able to convert an
EAP method into a compatible non-EAP form of the same
credential to suppress cryptographic binding. In addition,
an inner authentication may be available through an entirely
different means. For example, a Lightweight Directory Access
Protocol <xref target="RFC4510"/> or other directory server
may provide an attacker a way to get challenges and provide
responses for an authentication mechanism entirely outside
of the AAA/EAP context. An attacker with this capability may
be able to get around server policy requiring an inner
authentication be used only in a given type of tunnel.</t>
<figure title="Converting EAP Inner Authentication">
<artwork></artwork>
<postamble>An attacker can convert an inner authentication
using an EAP method to a inner authentication that does
not use EAP in some cases. This may avoid cryptographic
binding.</postamble>
</figure>
<figure title="Non-EAP Sources of Inner Authentication">
<artwork></artwork>
<postamble>An attacker may contact another authentication
resource to gain a challenge useful for an inner authentication. </postamble>
</figure>
<t>To Recap, the following policy conditions appear
sufficient to prevent a server insertion attack:<list
style="numbers">
<t>Peer and EAP server require a particular inner EAP
method used within a particular tunnel method</t>
<t>The inner EAP method's authentication is only
available within the tunnel and through no other means
including non-EAP means</t>
<t>The inner EAP method produces a key
</t>
<t>The tunnel method supports cryptographic
authentication and the peer requires the other end of
the tunnel to prove knowledge of the inner MSK.</t>
</list>
</t>
</section>
<section title="Existing Cryptographic Binding">
<t>The most advanced examples of cryptographic binding today
work at two levels. First, the server and peer prove to each
other knowledge of the inner MSK. Then, the inner MSK is
combined into some outer key material to form the tunnel's
keys. This is sufficient to detect an inserted server or
peer provided that the attacker does not learn the inner
MSK. This seems sufficient to defend against attackers who
cannot act as a legitimate NAS.</t>
<t>The definition of cryptographic binding in RFC 3748 does
not require these steps. To meet that definition it would be
sufficient for a peer to prove knowledge of the inner key to
the EAP server. This would open some additional attacks. For
example by indicating success an attacker might be able to
mask a cryptographic binding failure. Especially if only the
tunnel key material is used for the final keys, the peer is
unlikely to be able to detect the failure.</t>
<t>As discussed in the previous section, cryptographic
binding is only effective when the inner method is EAP.</t>
</section>
<section title="Introducing Mutual Cryptographic Binding">
<t>Cryptographic binding can be strengthened when the inner
EAP method supports an Extended Master Session Key
(EMSK). The EMSK is never disclosed to any party other than
the EAP server or peer, so even a legitimate NAS cannot
learn the EMSK. So, if the same techniques currently applied
to the inner MSK are applied to the inner EMSK, then
condition 3 (completing tunnel authentication) will not hold
because the attacker cannot complete this new form of
cryptographic binding. This does not prevent the attacker
from learning confidential information such as a channel
binding request sent over the tunnel prior to cryptographic
binding.</t>
<t>Obviously as with all forms of cryptographic binding,
cryptographic binding only works for key-deriving inner EAP
methods. Also, some deployments (see <xref
target="GOODMITM"/> insert intermediates between the peer
and the EAP server. EMSK-based cryptographic binding is
incompatible with these deployments because the intermediate
cannot learn the EMSK.</t>
<t>Formally, mutual cryptographic binding is a security
claim for EAP tunnel methods that holds when:<list
style="numbers">
<t>The peer proves to the server that the peer
participating in any inner method is the same as the peer
for the tunnel method. <vspace/></t>
<t>The server proves to the peer that the server for any
inner method is the same as the server for the tunnel
method.<vspace/></t>
<t>The MSK and EMSK for the tunnel depend on the MSK and
EMSK of inner methods.<vspace/></t>
<t>A tunnel method may support mutual cryptographic
binding optionally and fall back to MSK-based cryptographic
binding (for example when an intermediate is intended) but
MUST NOT prevent an attacker who is unaware of the inner MSK
from forcing a bid-down to MSK-based cryptographic
binding. Peers MUST be able to require that if mutual
cryptographic binding is unavailable, the authentication
will fail.<vspace/></t>
<t>Proofs offered need to be secure even against
attackers who know the inner method MSK.<vspace/></t>
</list>
</t>
<t>If mutual cryptographic binding is not an optional
facility it provides a strong defense against server
insertion attacks and other tunnel MITM attacks for inner
methods that provide an EMSK. The strength of the defense is
dependent on the strength of the inner method. The value of
mutual cryptographic binding is reduced somewhat if it is an
optional feature. It permits configurations where a peer
requires mutual cryptographic binding if the peer has
insufficient information configured to validate the
certificate and identity of an EAP server.</t>
</section>
<section title="Mix Key into Long-Term Credentials">
<t>Another defense against tunnel MITM attacks potentially
including server insertion attacks is to use a different
credential for tunneled methods from other
authentications. This may prevent the second condition
(attacker being able to respond to inner authentication)
from taking place. For example, if key material from the
tunnel is mixed into a shared secret or password that is the
basis of the inner authentication, then the second condition
will not hold unless the attacker already knows this shared
secret. The advantage of this approach is that it seems to
be the only way to strengthen non-EAP inner authentications
within a tunnel.</t>
<t>There are several disadvantages. Choosing a function to
mix the tunnel key material into the inner authentication
will be very dependent on the inner authentication. In
addition, this appears to involve a layering
violation. However, exploring the possibility of providing a
solution like this seems important because it can function
for inner authentications where no other approach will
work.</t>
</section>
</section>
<section anchor="GOODMITM" title="Intended Intermediates">
<t>Some deployments introduce a tunnel server separate from
the EAP server; see <xref target="RFC5281"/> for an example of
this style of deployment. The only difference between such an
intermediate and an attacker is that the intermediate provides
some function valuable to the peer or EAP server and that the
intermediate is trusted by the peer. If peers are configured
with the necessary information to validate certificates of
these intermediates and to confirm their identity, then tunnel
MITM and inserted server attacks can be defended against. The
intermediates need to be trusted with regard to channel
binding and other services that the peer depends on.</t>
<t>Support for trusted intermediates is not a requirement
according to the tunnel method requirements.</t>
<t>It seems reasonable to treat trusted intermediates as a
special case if they are supported and to focus on the
security of the case where there are not intermediates in the
tunnel as the common case.</t>
</section>
</section>
<section title="Recommendations">
<section title="Mutual Cryptographic Binding">
<t>The EAP Tunnel Method <xref
target="I-D.ietf-emu-eap-tunnel-method"/> should gain support
for mutual cryptographic binding.</t>
<t>As channel binding support is added to existing EAP
methods, mutual cryptographic binding should also be added to
these methods. Mutual cryptographic binding may also be
valuable when other services are added to EAP methods that may
require a peer trust an EAP server.</t>
</section>
<section title="State Tracking">
<t>Today, mutual authentication in EAP is thought of as a
security claim about a method. However, in practice it's an
attribute of a particular exchange. Mutual authentication can
be obtained via checking certificates, through mutual
cryptographic binding, or in very controlled cases through
carefully crafted peer and server policy combined with
existing cryptographic binding. Using services like channel
binding that involve the peer trusting the EAP server should
require mutual authentication be present in the session. </t>
<t>to accomplish this, implementations including channel
binding or other peer services MUST track whether mutual
authentication has happened. They SHOULD default to not
permitting these peer services unless mutual authentication
has happened. They SHOULD support a configuration where the
peer fails to authenticate unless mutual authentication takes
place. Discussion of whether this configuration should be
recommended as a default is required.</t>
<t>The EAP Tunnel Method should permit peers to force
authentication failure if they are unable to perform mutual
authentication. The protocol should permit this to be deferred
until after mutual cryptographic binding is considered.</t>
<t>Services such as channel binding should be deferred until
after cryptographic binding/mutual cryptographic binding.</t>
</section>
<section title="Certificate Naming">
<t>Work is required to promote interoperable deployment of
server certificate validation by peers. A standard way to name
EAP servers is required. Recommendations for what name forms
peers should implement is required.</t>
</section>
<section title="Inner Mixing">
<t>More consideration of the proposal to mix some key material
into inner authentications is desired. As stated today, the
proposal is under-defined and fairly invasive. Are there
versions of this proposal that would be valuable? Is there a
way to view it as something more abstract so that it does not
involve tunnel and inner method specific combinatorial explosion?</t>
</section>
</section>
<section title="Survey of Tunnel Methods"></section>
<section title="Survey of Inner Methods">
</section>
<section title="Security Considerations"></section>
<section title="Acknowledgements">
<t>The authors would like to thank Alan DeKok for helping to
explore these attacks. Alan focused the discussion on the
importance of inner authentications that are not EAP and
proposed mixing in key material as a way to resolve these
authentications.</t>
<t>Jari Arkko provided a review of the attack and valuable
context on past efforts in developing cryptographic binding.</t>
<t>Sam Hartman's and margaret Wasserman's work on this memo is
funded by Huawei.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3778'?>
</references>
<references title="Informative References">
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5281'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4851'?>
<?rfc
include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2759'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4510'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3//reference.I-D.ietf-emu-chbind'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3//reference.I-D.ietf-nea-pt-eap'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3//reference.I-D.ietf-abfab-gss-eap'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3//reference.I-D.ietf-emu-eaptunnel-req'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3//reference.I-D.ietf-emu-eap-tunnel-method'?>
<reference anchor="TUNNEL-MITM">
<front>
<title></title>
<author></author>
<date />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:11:33 |