One document matched: draft-ietf-nea-pt-eap-01.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 RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC3478 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3478.xml">
<!ENTITY RFC3748 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml">
<!ENTITY RFC4851 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4851.xml">
<!ENTITY RFC5209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5209.xml">
<!ENTITY RFC5216 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5216.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC5281 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5281.xml">
<!ENTITY RFC5792 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5792.xml">
<!ENTITY RFC5793 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5793.xml">
<!ENTITY RFC5929 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5929.xml">
<!ENTITY RFC5996 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5996.xml">
<!ENTITY RFC2434 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2434.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
<!ENTITY I-D.ietf-nea-pt-tls SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nea-pt-tls.xml">
<!ENTITY I-D.ietf-emu-eaptunnel-req SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-emu-eaptunnel-req.xml">
<!ENTITY I-D.salowey-nea-asokan SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.salowey-nea-asokan.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-ietf-nea-pt-eap-01" 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="NEA PT-EAP">PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Nancy Cam-Winget" initials="N" role="editor" surname="Cam-Winget">
<organization abbrev="">Cisco Systems</organization>
<address>
<postal>
<street>80 West Tasman Drive</street>
<city>San Jose</city>
<country>US</country>
<code>95134</code>
<region>CA</region>
<country>USA</country>
</postal>
<email>ncamwing@cisco.com</email>
</address>
</author>
<author fullname="Paul Sangster" role="editor" surname="Sangster">
<organization>Symantec Corporation</organization>
<address>
<postal>
<street>6825 Citrine Drive</street>
<city>Carlsbad</city>
<code>92009</code>
<region>CA</region>
<country>USA</country>
</postal>
<email>paul_sangster@symantec.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="March" year="2012"/>
<area>Security</area>
<workgroup>NEA</workgroup>
<abstract>
<t>This document specifies PT-EAP, an EAP based Posture Transport (PT)
protocol designed to be used only inside TLS protected tunnel method.
As such, the document also describes the intended applicability of
PT-EAP as well as the evaluation against the requirements defined
in the NEA Requirements and PB-TNC specifications.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document specifies PT-EAP, a Posture Transport (PT) protocol
protected by an outer TLS tunnel or equivalent protection.
The PT protocol in the NEA architecture is responsible for transporting
PB-TNC batches (often containing PA-TNC <xref target="RFC5792"/> attributes) across
the network between the NEA Client and NEA Server. The PT protocol
must be protected by an outer TLS-based tunnel to ensure the exchanged messages are
protected from a variety of threats from hostile intermediaries.</t>
<t> NEA protocols are intended to be used both for pre-admission assessment of endpoints
joining the network and to assess endpoints already present on the network. In order
to support both usage models, two types of PT protocols are needed. One type of PT
operates after the endpoint has an assigned IP address, layering on top of the IP
protocol to carry a NEA exchange. The other type of PT operates before the endpoint
gains any access to the IP network. This specification defines PT-EAP, the PT
protocol used to assess endpoints before they gain access to the network.</t>
<t> PT-EAP is an inner EAP <xref target="RFC3748"/> method designed to be used
under a protected tunnel such as EAP-FAST <xref target="RFC4851"/>
or EAP-TTLS <xref target="RFC5281"/>. </t>
<section title="Prerequisites">
<t>This document does not define an architecture or reference model. Instead, it defines a
protocol that works within the reference model described in the NEA Requirements
specification <xref target="RFC5209"/>. The reader is assumed to be thoroughly familiar
with that document.</t>
</section>
<section anchor="Conventions" title="Message Diagram Conventions">
<t> This specification defines the syntax of PT-EAP messages using diagrams.
Each diagram depicts the format and size of each field in bits. Implementations
MUST send the bits in each diagram as they are shown, traversing the diagram from
top to bottom and then from left to right within each line (which represents a
32-bit quantity). Multi-byte fields representing numeric values MUST be sent in
network (big endian) byte order.</t>
<t> Descriptions of bit field (e.g. flag) values are described referring to the
position of the bit within the field. These bit positions are numbered from the
most significant bit through the least significant bit so a one octet field with
only bit 0 set has the value 0x80.</t>
</section>
<section title="Terminology">
<t> This document reuses many terms defined in the NEA Requirements document
<xref target="RFC5209"/>, such as Posture Transport Client and Posture Transport Server.
The reader is assumed to have read that document and understood it.</t>
<t>When defining the PT-EAP method, this specification does not use the terms "EAP peer"
and "EAP authenticator". Instead, it uses the terms "NEA Client" and "NEA Server"
since those are considered to be more familiar to NEA WG participants. However,
these terms are equivalent for the purposes of these specifications. The part
of the NEA Client that terminates PT-EAP (generally in the Posture Transport
Client) is the EAP peer for PT-EAP. The part of the NEA Server that terminates
PT-EAP (generally in the Posture Transport Server) is the EAP authenticator for PT-EAP.</t>
</section>
<section title="Conventions used in this document">
<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 title="Compatibility with other Specifications">
<t>One of the goals of the NEA effort is to deliver a single set of
endpoint assessment standards, agreed upon by all parties. For
this reason, the Trusted Computing Group (TCG) will be replacing
its existing posture transport protocols with new versions that
are equivalent to and interoperable with the NEA specifications.</t>
</section>
</section>
<section title="Use of PT-EAP">
<t> PT-EAP is designed to encapsulate PB-TNC batches in a simple EAP method
that can be carried within EAP tunnel methods. The EAP tunnel methods
provide confidentiality and message integrity, so PT-EAP does not have
to do so. Therefore, PT-EAP MUST only be used inside an EAP tunnel
method that provides strong cryptographic authentication (possibly
server only), message integrity and confidentiality services.</t>
</section>
<section title="definition of PT-EAP">
<t> The PT-EAP protocol operates between a Posture Transport Client and a Posture
Transport Server, allowing them to send PB-TNC batches to each other over an EAP
tunnel method. When PT-EAP is used, the Posture Transport Client in the NEA reference
model acts as an EAP peer (terminating the PT-EAP method on the endpoint) and
the Posture Transport Server acts as an EAP authenticator (terminating the PT-EAP
method on the NEA Server).</t>
<t>This section describes and defines the PT-EAP method. First, it provides a protocol
overview and a flow diagram. Second, it describes specific features like version
negotiation. Third, it gives a detailed packet description. Finally,
it describes how the tls-unique channel binding <xref target="RFC5929"/> may be used to
PA-TNC exchanges to the EAP tunnel method, defeating MITM attacks such as
the Asokan attack <xref target="Asokan"/>. </t>
<section title="Protocol Overview">
<t> PT-EAP has two phases that follow each other in strict sequence: negotiation
and data transport.</t>
<t> The PT-EAP method begins with the negotiation phase. The NEA Server starts this
phase by sending an PT-EAP Start message: an EAP Request message of type PT-EAP
with the S (Start) flag set. The NEA Server also sets the Version field as described
in <xref target="Negotiation"/>. This is the only message in the negotiation
phase. </t>
<t>The data transport phase is the only phase of PT-EAP where PB-TNC batches are allowed
to be exchanged. This phase always starts with the NEA Client sending a PB-TNC
batch to the NEA Server. The NEA Client and NEA Server then engage in a round-robin
exchange with one PB-TNC batch in flight at a time. The data transport phase always
ends with an EAP Response message from the NEA Client to the NEA Server. This
message may be empty (not contain any data) if the NEA Server has just sent the
last PB-TNC batch in the PB-TNC exchange.</t>
<t> At the end of the PT-EAP method, the NEA Server will indicate success or failure to
the EAP tunnel method. Some EAP tunnel methods may provide explicit confirmation of
inner method success; others may not. This is out of scope for the PT-EAP method specification.
Successful completion of PT-EAP does not imply successful completion of the overall
authentication nor does PT-EAP failure imply overall failure. This depends on the
administrative policy in place.</t>
<t> The NEA Server and NEA Client may engage in an abnormal termination of the PT-EAP
exchange at any time by simply stopping the exchange. This may also require terminating
the EAP tunnel method, depending on the capabilities of the EAP tunnel method. </t>
<t> The NEA Server and NEA Client MUST follow the protocol sequence described in this section.</t>
</section>
<section anchor="Negotiation" title="Version Negotiation">
<t> PT-EAP version negotiation takes place in the first PT-EAP message sent by the
NEA Server (the Start message) and the first PT-EAP message sent by the NEA Client
(the response to the Start message). The NEA Server MUST set the Version field in the
Start message to the maximum PT-EAP version that the NEA Server supports and is
willing to accept.</t>
<t> The NEA Client chooses the PT-EAP version to be used for the exchange and places
this value in the Version field in its response to the Start message. The NEA Client
SHOULD choose the value sent by the NEA Server if the NEA Client supports it. However,
the NEA Client MAY set the Version field to a value less than the value sent by the
NEA Server (for example, if the NEA Client only supports lesser PT-EAP versions).
If the NEA Client only supports PT-EAP versions greater than the value sent by
the NEA Server, the EAP client MUST abnormally terminate the EAP negotiation.</t>
<t>If the version sent by the NEA Client is not acceptable to the NEA Server, the NEA
Server MUST terminate the PT-EAP session immediately. Otherwise, the version
sent by the NEA Client is the version of PT-EAP that MUST be used. Both the NEA
Client and the NEA Server MUST set the Version field to the chosen version number
in all subsequent PT-EAP messages in this exchange.</t>
<t>This specification defines version 1 of PT-EAP. Version 0 is reserved and MUST
never be sent. New versions of PT-EAP (values 2-7) may be defined by Standards
Action, as defined in <xref target="RFC5226"/>.</t>
</section>
<section title="PT-EAP Message Format">
<t> This section provides a detailed description of the fields in an PT-EAP message.
For a description of the diagram conventions used here, see
<xref target="Conventions"/>. Since PT-EAP is an EAP method, the first four
fields in each message are mandated by and defined in EAP.</t>
<figure align="center">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | Ver | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Length | Data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list hangIndent="0" style="hanging">
<t hangText="Code">
<vspace blankLines="1"/> The Code field is one octet and identifies the
type of the EAP message. The only values used for PT-EAP are:
<vspace blankLines="1"/>
</t>
</list>
<list hangIndent="3" style="hanging">
<t hangText="1">Request</t>
<t hangText="2">Response</t>
</list>
<vspace blankLines="1"/>
<list hangIndent="0" style="hanging">
<t hangText="Identifier">
<vspace blankLines="1"/> The Identifier field is one octet and aids
in matching Responses with Requests.
<vspace blankLines="1"/>
</t>
<t hangText="Length">
<vspace blankLines="1"/>The Length field is two octets and indicates
the length in octets of this PT-EAP message, starting from the Code field.
<vspace blankLines="1"/>
</t>
<t hangText="Type">
<vspace blankLines="1"/> TBD </t>
<t hangText="Flags">
<vspace blankLines="1"/>
</t>
</list>
</t>
<figure>
<artwork><![CDATA[
+-+-+-+-+-+
|L S R R R|
+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<vspace blankLines="1"/>
<list hangIndent="3" style="hanging">
<t hangText="L: Length included">
<vspace blankLines="1"/> Indicates the presence of the Data Length field
in the PT-EAP message. This flag MUST be set for an PT-EAP message that
contains Data (messages).
<vspace blankLines="1"/>
</t>
<t hangText="S: Start">
<vspace blankLines="1"/> Indicates the beginning of an PT-EAP exchange.
This flag MUST be set only for the first message from the NEA Server. If
the S flag is set, the EAP message MUST NOT contain Data or have the L flag set.
<vspace blankLines="1"/>
</t>
<t hangText="R: Reserved">
<vspace blankLines="1"/> This flag MUST be set to 0 and ignored upon receipt.
<vspace blankLines="1"/>
</t>
</list>
</t>
<t>
<list hangIndent="0" style="hanging">
<t hangText="Version">
<vspace blankLines="1"/>
This field is used for version negotiation, as described in <xref target="Negotiation"/>.
<vspace blankLines="1"/>
</t>
<t hangText="Data Length">
<vspace blankLines="1"/> The Data Length field MUST
be set in the PT-EAP message if and only if the L flag is set.
<vspace blankLines="1"/>
</t>
<t hangText="Data">
<vspace blankLines="1"/>
Variable length data. The length of the Data field in a particular PT-EAP message
may be determined by subtracting the length of the PT-EAP header fields from the
value of the two octet Length field.
</t>
</list>
</t>
<!-- This is an empty comment string to make xml2rfc happy -->
<!-- 2nd comment string to check -->
</section>
<section anchor="MIM" title="Preventing MITM Attacks with Channel Bindings">
<t> As described in the NEA Asokan Attack Analysis [16], a sophisticated MITM attack can
be mounted against NEA systems. The attacker forwards PA-TNC messages from a healthy
machine through an unhealthy one so that the unhealthy machine can gain network access.
Because there are easier attacks on NEA systems, like having the unhealthy machine lie
about its configuration, this attack is generally only mounted against machines with
an External Measurement Agent (EMA). The EMA is a separate entity, difficult to compromise,
which measures and attests to the configuration of the endpoint. </t>
<t>To protect against NEA Asokan attacks, it is necessary for the Posture Broker on an
EMA-equipped endpoint to pass the tls-unique channel binding <xref target="RFC5929"/> for PT-EAP's
tunnel method to the EMA.
This value can then be included in the EMA's attestation so that the Posture Validator
responsible may then confirm that the value matches the
tls-unique channel binding for its end of the tunnel.
If the tls-unique values between the NEA Client and NEA Server match endpoint, then
the posture sent by the EMA (and thus the NEA Client) is from the same endpoint as
the client side of the TLS connection
(since the endpoint knows the tls-unique value) so no man-in-the-middle is forwarding posture.
If they differ, an attack has been detected and the Posture Validator SHOULD fail its
verification. </t>
</section>
</section>
<section title="Security Considerations">
<t>This section discusses the major threats and countermeasures provided by PT-EAP. As
discussed throughout the document, the PT-EAP method is designed to run
inside an EAP tunnel method which is capable of protecting the PT-EAP protocol from many
threats. Since the EAP tunnel method will be specified separately, these security
considerations specify requirements on the tunnel method but do not evaluate its ability
to meet those requirements. The security considerations and requirements for the NEA
can be found in <xref target="RFC5209" />.</t>
<section anchor="Trust" title="Trust Relationships">
<t>In order to understand where security countermeasures are necessary,
this section starts with a discussion of where the NEA architecture
envisions some trust relationships between the processing elements
of the PT-EAP protocol. The following sub-sections discuss the
trust properties associated with each portion of the NEA reference
model directly involved with the processing of the PT-EAP protocol
flowing inside an EAP tunnel.</t>
<section title="Posture Transport Client">
<t>The Posture Transport Client is trusted by the Posture Broker Client to:</t>
<t>
<list style="symbols">
<t>Not to observe, fabricate or alter the contents of the PB-TNC batches received
from the network</t>
<t>Not to observe, fabricate or alter the PB-TNC batches passed down from the
Posture Broker Client for transmission on the network</t>
<t>Transmit on the network any PB-TNC batches passed down from the Posture Broker
Client</t>
<t>Deliver properly security protected messages received from the network that are
destined for the Posture Broker Client</t>
<t>Provide configured security protections (e.g. authentication, integrity and
confidentiality) for the Posture Broker Client's PB-TNC batches sent on the network</t>
<t>Expose the authenticated identity of the Posture Transport Server</t>
<t>Verify the security protections placed upon messages received from the network
to ensure the messages are authentic and protected from attacks on the network</t>
<t>Provide a secure, reliable, in order delivery, full duplex transport for the
Posture Broker Client's messages</t>
</list>
</t>
<t>The Posture Transport Client is trusted by the Posture Transport Server to:</t>
<t>
<list style="symbols">
<t>Not send malicious traffic intending to harm (e.g. denial of service) the
Posture Transport Server</t>
<t>Not to intentionally send malformed messages to cause processing problems
for the Posture Transport Server</t>
<t>Not to send invalid or incorrect responses to messages (e.g. errors when
no error is warranted)</t>
<t>Not to ignore or drop messages causing issues for the protocol processing </t>
<t>Verify the security protections placed upon messages received from the
network to ensure the messages are authentic and protected from attacks
on the network</t>
</list>
</t>
</section>
<section title="Posture Transport Server">
<t> The Posture Transport Server is trusted by the Posture Broker Server to:</t>
<t>
<list style="symbols">
<t>Not to observe, fabricate or alter the contents of the PB-TNC batches
received from the network</t>
<t>Not to observe, fabricate or alter the PB-TNC batches passed down from the
Posture Broker Server for transmission on the network</t>
<t>Transmit on the network any PB-TNC batches passed down from the Posture
Broker Server</t>
<t>Deliver properly security protected messages received from the network
that are destined for the Posture Broker Server</t>
<t>Provide configured security protections (e.g. authentication, integrity
and confidentiality) for the Posture Broker Server's messages sent on the network</t>
<t>Expose the authenticated identity of the Posture Transport Client</t>
<t>Verify the security protections placed upon messages received from the
network to ensure the messages are authentic and protected from attacks
on the network</t>
</list>
</t>
<t>The Posture Transport Server is trusted by the Posture Transport Client to:</t>
<t>
<list style="symbols">
<t>Not send malicious traffic intending to harm (e.g. denial of service) the
Posture Transport Server</t>
<t>Not to send malformed messages </t>
<t>Not to send invalid or incorrect responses to messages (e.g. errors when
no error is warranted)</t>
<t>Not to ignore or drop messages causing issues for the protocol processing </t>
<t>Verify the security protections placed upon messages received from the network
to ensure the messages are authentic and protected from attacks on the network</t>
</list>
</t>
</section>
</section>
<section title="Security Threats and Countermeasures">
<t> Beyond the trusted relationships assumed in <xref target="Trust"/>, the PT-EAP EAP method
faces a number of potential security attacks that could require security countermeasures.</t>
<t>Generally, the PT protocol is responsible for providing strong security protections for
all of the NEA protocols so any threats to PT's ability to protect NEA protocol messages
could be very damaging to deployments. For the PT-EAP method, most of the cryptographic
security is provided by the outer EAP tunnel method and PT-EAP is encapsulated within
the protected tunnel. Therefore, this section highlights the cryptographic requirements
that need to be met by the EAP tunnel method carrying PT-EAP in order to meet the NEA PT
requirements. </t>
<t> Once the message is delivered to the Posture Broker Client or Posture Broker Server,
the posture brokers are trusted to properly safely process the messages.</t>
<section title="Message Theft">
<t>When PT-EAP messages are sent over unprotected network links or spanning local
software stacks that are not trusted, the contents of the messages may be subject
to information theft by an intermediary party. This theft could result in information
being recorded for future use or analysis by the adversary. Messages observed by
eavesdroppers could contain information that exposes potential weaknesses in the
security of the endpoint, or system fingerprinting information easing the ability
of the attacker to employ attacks more likely to be successful against the endpoint.
The eavesdropper might also learn information about the endpoint or network policies
that either singularly or collectively is considered sensitive information.
For example, if PT-EAP is housed in an EAP tunnel method that does not provide
confidentiality protection, an adversary could observe the PA-TNC attributes
included in the PB-TNC batch and determine that the endpoint is lacking patches,
or particular sub-networks have more lenient policies.</t>
<t>In order to protect against NEA assessment message theft, the EAP tunnel method
carrying PT-EAP MUST provide strong cryptographic authentication, integrity
and confidentiality protection. The use of bi-directional authentication in the
EAP tunnel method carrying PT-EAP ensures that only properly authenticated and
authorized parties may be involved in an assessment message exchange. When
PT-EAP is carried within a cryptographically protected EAP tunnel method like
EAP-TTLS, all of the PB-TNC and PA-TNC protocol messages contents are hidden
from potential theft by intermediaries lurking on the network.</t>
</section>
<section title="Message Fabrication">
<t> Attackers on the network or present within the NEA system could introduce fabricated
PT-EAP messages intending to trick or create a denial of service against aspects of an assessment.
For example, an adversary could attempt to insert into the message exchange fake PT-EAP error codes
in order to disrupt communications.</t>
<t>The EAP tunnel method carrying an PT-EAP method needs to provide strong security
protections for the complete message exchange over the network. These security
protections prevent an intermediary from being able to insert fake messages into
the assessment. For example, the EAP-TTLS method's use of hashing algorithms
provides strong integrity protections that allow for detection of any changes in
the content of the message exchange. Adversaries are unable to
observe the PT-EAP method housed inside of an encrypted EAP tunnel method
(e.g. EAP-TTLS) because the messages are encrypted by the TLS
<xref target="RFC5246"/> ciphers. Similarly, an attacker would have difficulty determining
where to insert the falsified message since the attacker is unable to determine
where the message boundaries exist.</t>
</section>
<section title="Message Modification">
<t> This attack could allow an active attacker capable of intercepting a message to modify
a PT-EAP message or transported PA-TNC attribute to a desired value to ease the
compromise of an endpoint. Without the ability for message recipients to detect
whether a received message contains the same content as what was originally sent,
active attackers can stealthily modify the attribute exchange.</t>
<t>The PT-EAP method leverages the EAP tunnel method (e.g. EAP-TTLS) to provide strong
authentication and integrity protections as a countermeasure to this threat. The
bi-directional authentication prevents the attacker from acting as an active
man-in-the-middle to the protocol that could be used to modify the message exchange.
The strong integrity protections (hashing) offered by EAP-TTLS allows the PT-EAP
message recipients to detect message alterations by other types of network based
adversaries. Because PT-EAP does not itself provide explicit integrity protection
for the PT-EAP payload, an EAP tunnel method that offers strong integrity protection
is required to mitigate this threat.</t>
</section>
<section title="Denial of Service">
<t>A variety of types of denial of service attacks are possible against the PT-EAP
if the message exchange are left unprotected while traveling over the network.
The Posture Transport Client and Posture Transport Server are trusted not to
participate in the denial of service of the assessment session, leaving the
threats to come from the network.</t>
<t> The PT-EAP method primarily relies on the outer EAP tunnel method to provide
strong authentication (at least of one party) and deployers are expected to leverage
other EAP methods to authenticate the other party (typically the client) within
the protected tunnel. The use of a protected bi-directional authentication will
prevent unauthorized parties from participating in a PT-EAP exchange. </t>
<t>After the cryptographic authentication by the EAP tunnel method, the session
can be encrypted and hashed to prevent undetected modification that could create
a denial of service situation. However it is possible for an adversary to alter the
message flows causing each message to be rejected by the recipient because it fails
the integrity checking.</t>
</section>
<section title="NEA Asokan Attacks">
<t>As described in <xref target="MIM"/>. and in the NEA Asokan Attack Analysis
<xref target="Asokan"/>, a sophisticated MITM attack can be mounted against
NEA systems. The attacker forwards PA-TNC messages from a healthy machine
through an unhealthy one so that the unhealthy machine can gain network access.
<xref target="MIM"/> and the NEA Asokan Attack Analysis provide a detailed
description of this attack and of the countermeasures that can be employed against it.</t>
<t> Because lying endpoint attacks are much easier than Asokan attacks and the
only known effective countermeasure against lying endpoint attacks is the use
of an External Measurement Agent (EMA), countermeasures against an Asokan
attack are not necessary unless an EMA is in use. However, PT-EAP implementers
may not know whether an EMA will be used with their implementation. Therefore,
PT-EAP implementers SHOULD support these countermeasures by providing the value
of the tls-unique channel binding to higher layers in the NEA reference model:
Posture Broker Clients, Posture Broker Servers, Posture Collectors, and Posture
Validators.</t>
</section>
</section>
<section anchor="Reqmts" title="Requirements for EAP Tunnel Methods">
<t>Because the PT-EAP inner method described in this specification relies on the outer
EAP tunnel method for a majority of its security protections, this section
reiterates the PT requirements that MUST be met by the IETF standard EAP tunnel
method for use with PT-EAP.</t>
<t>The security requirements described in this specification MUST be implemented in
any product claiming to be PT-EAP compliant. The decision of whether a particular
deployment chooses to use these protections is a deployment issue. A customer
may choose to avoid potential deployment issues or performance penalties
associated with the use of cryptography when the required protection has been
achieved through other mechanisms (e.g. physical isolation). If security
mechanisms may be deactivated by policy, an implementation SHOULD offer an
interface to query how a message will be (or was) protected by PT so higher
layer NEA protocols can factor this into their decisions.</t>
<t><xref target="RFC5209">RFC 5209</xref> includes the following requirement that is to be applied during the
selection of the EAP tunnel method(s) used in conjunction with PT-EAP:</t>
<t>
<list hangIndent="0" style="hanging">
<t>PT-2: The PT protocol MUST be capable of supporting mutual authentication,
integrity, confidentiality, and replay protection of the PB messages
between the Posture Transport Client and the Posture Transport Server.</t>
</list>
</t>
<t>Note that mutual authentication could be achieved by a combination of a strong
authentication of one party (e.g. TLS server when EAP-TTLS is used) by the EAP
tunnel method in conjunction with a second authentication of the other party
(e.g. client authentication inside the protected tunnel) by another EAP method
running prior to PT-EAP.</t>
<t> Having the Posture Transport Client always authenticate the Posture Transport Server
provides assurance to the NEA Client that the NEA Server is authentic (not a rogue
or MiTM) prior to disclosing secret or potentially privacy sensitive information
about what is running or configured on the endpoint. However the NEA Server's
policy may allow for the delay of the authentication of the NEA Client until a
suitable protected channel has been established allowing for non-cryptographic
NEA Client credentials (e.g. username/password) to be used. Whether the
communication channel is established with mutual or server-side only authentication,
the resulting channel needs to provide strong
integrity and confidentiality protection to its contents. These protections
are to be bound to at least the authentication of the NEA Server by the NEA Client,
so the session
is cryptographically bound to a particular authentication event.</t>
<t>To support countermeasures against NEA Asokan attacks as described in
<xref target="MIM"/>. the EAP Tunnel Method used with PT-EAP will need to
support the tls-unique channel binding. This should not be a high bar since all
EAP tunnel methods currently support this but not all implementations of those methods
may do so.</t>
</section>
<section title="Candidate EAP Tunnel Method Protections">
<t>This section discusses how PT-EAP is used within various EAP tunnel methods to meet
the PT requirements from section <xref target="Reqmts"/>. </t>
<t>EAP-FAST <xref target="RFC4851" /> and EAP-TTLS <xref target="RFC5281" />make use of TLS <xref target="RFC5246"/> to protect the
transport of information between the NEA Client and NEA Server. Each of these
EAP tunnel methods has two phases. In the first phase, a TLS tunnel is established
between NEA Client and NEA Server. In the second phase, the tunnel is used to
pass other information. PT-EAP requires that establishing this tunnel include at
least an authentication of the NEA Server by the NEA Client.</t>
<t>The phase two dialog may include authentication of the user by doing other EAP
methods or in the case of TTLS by using non-EAP authentication dialogs.
PT-EAP is also carried by the phase two tunnel allowing the NEA assessment to
be within an encrypted and integrity protected transport.</t>
<t>With all these methods (e.g. EAP-FAST <xref target="RFC4851"/> and EAP-TTLS <xref target="RFC5281"/>,
a cryptographic key is derived from the authentication
that may be used to secure later transmissions. Each of these methods employs
at least a NEA Server authentication using an X.509 certificate. Within each
EAP tunnel method will exist a set of inner EAP method (or an equivalent using
TLVs if inner methods aren't directly supported.) These inner methods may
perform additional security handshakes including more granular authentications
or exchanges of integrity information (such as PT-EAP.) At some point after
the conclusion of each inner EAP method, some of the methods will export the
established secret keys to the outer tunnel method. It's expected that the
outer method will cryptographically mix these keys into any keys it is currently
using to protect the session and perform a final operation to determine whether
both parties have arrived at the same mixed key. This cryptographic binding of
the inner method results to the outer methods keys is essential for detection of
conventional (non-NEA) Asokan attacks. </t>
</section>
<section title="Security Claims for PT-EAP as per RFC3748">
<t>This section summarizes the security claims, for this specification, as required by RFC3748 Section 7.2:</t>
<figure>
<artwork><![CDATA[
Auth. mechanism: None
Ciphersuite negotiation: No
Mutual authentication: No
Integrity protection: No
Replay protection: No
Confidentiality: No
Key derivation: No
Key strength: N/A
Dictionary attack resistant: N/A
Fast reconnect: No
Crypt. binding: N/A
Session independence: N/A
Fragmentation: Yes
Channel binding: No
]]></artwork>
</figure>
</section>
</section>
<section title="Privacy Considerations">
<t>The role of PT-EAP is to act as a secure transport for PB-TNC over a network before
the endpoint has been admitted to the network. As a transport protocol, PT-EAP
does not directly utilize or require direct knowledge of any personally identifiable
information (PII). PT-EAP will typically be used in conjunction with other EAP
methods that provide for the user authentication (if bi-directional authentication is
used), so the user's credentials are not directly seen by the PT-EAP inner method.
Therefore, the Posture Transport Client and Posture Transport Server's implementation
of PT-EAP MUST NOT observe the contents of the carried PB-TNC batches that could
contain PII carried by PA-TNC or PB-TNC.</t>
<t>While PT-EAP does not provide cryptographic protection for the PB-TNC batches, it is
designed to operate within an EAP tunnel method that provides strong authentication,
integrity and confidentiality services. Therefore, it is important for deployers to
leverage these protections in order to prevent disclosure of PII potentially contained
within PA-TNC or PB-TNC within the PT-EAP payload.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This section provides guidance to the Internet Assigned numbers Authority (IANA)
regarding registration of values related to the PT-EAP protocol, in accordance
with <xref target="RFC2434">BCP 26</xref> </t>
<t> The EAP Method type for PT-EAP needs to be assigned. </t>
<t>This document also defines one new IANA registry: PT-EAP Versions.
This section explains how this registry works.
Because only eight (8) values are available in this registry, a high bar is
set for new assignments. The only way to register new values in this registry
is through Standards Action (via an approved Standards Track RFC). </t>
<section title="Registry for PT-EAP Versions">
<t>The name for this registry is "PT-EAP Versions". Each entry in this registry
includes a decimal integer value between 1 and 7 identifying the version, and a
reference to the RFC where the version is defined.</t>
<t>The following entries for this registry are defined in this document. Once
this document becomes an RFC, they will become the initial entries in the
registry for PT-EAP Versions. Additional entries to this registry are added by
Standards Action, as defined in <xref target="RFC5226">RFC 5226</xref>.</t>
<texttable>
<ttcol align="center">Value</ttcol>
<ttcol align="center">Defining Specification</ttcol>
<c>1</c>
<c>RFC # Assigned to this I-D</c>
</texttable>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Thanks to the Trusted Computing Group for contributing the initial text upon
which this document was based. </t>
<t>The authors of this draft would like to acknowledge the following people who
have contributed to or provided substantial input on the preparation of this
document or predecessors to it: Amit Agarwal, Morteza Ansari, Diana Arroyo,
Stuart Bailey, Boris Balacheff, Uri Blumenthal, Gene Chang, Scott Cochrane,
Pasi Eronen, Aman Garg, Sandilya Garimella, David Grawrock, Thomas Hardjono,
Chris Hessing, Ryan Hurst, Hidenobu Ito, John Jerrim, Meenakshi Kaushik,
Greg Kazmierczak, Scott Kelly, Bryan Kingsford, PJ Kirner, Sung Lee,
Lisa Lorenzin, Mahalingam Mani, Bipin Mistry, Seiji Munetoh, Rod Murchison,
Barbara Nelson, Kazuaki Nimura, Ron Pon, Ivan Pulleyn, Alex Romanyuk,
Ravi Sahita, Chris Salter, Mauricio Sanchez, Paul Sangster, Dean Sheffield,
Curtis Simonson, Jeff Six, Ned Smith, Michelle Sommerstad, Joseph Tardo,
Lee Terrell, Chris Trytten, and John Vollbrecht.</t>
<t> This document was prepared using template-bare-05.xml.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC3748;
&RFC5246;
&RFC5792;
&RFC5793;
&RFC5226;
&RFC2434;
<reference anchor="IEEE" target="http://standards.ieee.org/getieee802/download/802.1X-2010.pdf">
<!-- the following is the minimum to make xml2rfc happy -->
<front>
<title>LAN/MAN Standards Committee of the IEEE Computer Society, Standard for Local and Metrolpolitan Area Network - Port Based Network Access Control</title>
<author>
<organization>IEEE Std. 802.1X-2004</organization>
</author>
<date month="December" year="2004"/>
</front>
</reference>
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC5209;
&RFC3478;
&I-D.ietf-nea-pt-tls;
<!-- A reference written by by an organization not a person. -->
<reference anchor="TNC-Binding" target="http://www.trustedcomputinggroup.org/files/resource_files/51F0757E-1D09-3519-AD63B6FD099658A6/TNC_IFT_TLS_v1_0_r16.pdf">
<front>
<title>"TNC IF-T: Binding to TLS"</title>
<author>
<organization>Trusted Computing Group</organization>
</author>
<date month="May" year="2009"/>
</front>
</reference>
<reference anchor="Asokan" target="http://eprint.iacr.org/2002/163.pdf">
<front>
<title>"Man in the Middle Attacks in Tunneled Authentication Protocols"</title>
<author initials="N." surname="Asokan" fullname="N. Asokan">
<organization/>
</author>
<author initials="V." surname="Niemi" fullname="Valtteri Niemi">
<organization/>
</author>
<author initials="K." surname="Nyberg" fullname="Kaisa Nyberg">
<organization/>
</author>
<author>
<organization>Nokia Research Center, Finland</organization>
</author>
<date month="Nov" day="11" year="2002"/>
</front>
</reference>
&RFC4851;
&RFC5996;
&RFC5281;
&RFC5216;
&I-D.ietf-emu-eaptunnel-req;
&I-D.salowey-nea-asokan;
&RFC5929;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:39:15 |