diff options
Diffstat (limited to 'doc/rfc/rfc7171.txt')
| -rw-r--r-- | doc/rfc/rfc7171.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc7171.txt b/doc/rfc/rfc7171.txt new file mode 100644 index 0000000..6cb7253 --- /dev/null +++ b/doc/rfc/rfc7171.txt @@ -0,0 +1,1067 @@ + + + + + + +Internet Engineering Task Force (IETF) N. Cam-Winget +Request for Comments: 7171 Cisco Systems +Category: Standards Track P. Sangster +ISSN: 2070-1721 Symantec Corporation + May 2014 + + + PT-EAP: Posture Transport (PT) Protocol + for Extensible Authentication Protocol (EAP) Tunnel Methods + +Abstract + + This document specifies PT-EAP, a Posture Transport (PT) protocol + based on the Extensible Authentication Protocol (EAP) and designed to + be used only inside an EAP tunnel method protected by Transport Layer + Security (TLS). The document also describes the intended + applicability of PT-EAP. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7171. + +Copyright Notice + + Copyright (c) 2014 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + +Cam-Winget & Sangster Standards Track [Page 1] + +RFC 7171 NEA PT-EAP May 2014 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Prerequisites . . . . . . . . . . . . . . . . . . . . . . 3 + 1.2. Message Diagram Conventions . . . . . . . . . . . . . . . 3 + 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.4. Conventions Used in This Document . . . . . . . . . . . . 4 + 1.5. Compatibility with Other Specifications . . . . . . . . . 4 + 2. Use of PT-EAP . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Definition of PT-EAP . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 5 + 3.2. Version Negotiation . . . . . . . . . . . . . . . . . . . 6 + 3.3. PT-EAP Message Format . . . . . . . . . . . . . . . . . . 6 + 3.4. Preventing MITM Attacks with Channel Bindings . . . . . . 8 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 4.1. Trust Relationships . . . . . . . . . . . . . . . . . . . 9 + 4.1.1. Posture Transport Client . . . . . . . . . . . . . . 9 + 4.1.2. Posture Transport Server . . . . . . . . . . . . . . 10 + 4.2. Threats and Countermeasures . . . . . . . . . . . . . . . 10 + 4.2.1. Message Confidentiality . . . . . . . . . . . . . . . 11 + 4.2.2. Message Fabrication . . . . . . . . . . . . . . . . . 11 + 4.2.3. Message Modification . . . . . . . . . . . . . . . . 12 + 4.2.4. Denial of Service . . . . . . . . . . . . . . . . . . 12 + 4.2.5. NEA Asokan Attacks . . . . . . . . . . . . . . . . . 13 + 4.3. Candidate EAP Tunnel Method Protections . . . . . . . . . 13 + 4.4. Security Claims for PT-EAP as per RFC 3748 . . . . . . . 14 + 5. Requirements for EAP Tunnel Methods . . . . . . . . . . . . . 14 + 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 7.1. Registry for PT-EAP Versions . . . . . . . . . . . . . . 17 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 + 9.2. Informative References . . . . . . . . . . . . . . . . . 18 + +1. Introduction + + This document specifies PT-EAP, a Posture Transport (PT) protocol + protected by a TLS-protected EAP tunnel method. The PT protocol in + the Network Endpoint Assessment (NEA) architecture is responsible for + transporting Posture Broker (PB-TNC [RFC5793]) batches, often + containing Posture Attributes (PA-TNC [RFC5792]), across the network + between the NEA Client and NEA Server. The PT-EAP protocol must be + protected by an outer TLS-based EAP tunnel method to ensure the + exchanged messages are protected from a variety of threats from + hostile intermediaries. + + + + + +Cam-Winget & Sangster Standards Track [Page 2] + +RFC 7171 NEA PT-EAP May 2014 + + + NEA protocols are intended to be used both for pre-admission + assessment of endpoints joining the network and assessment of + endpoints already present on the network. In order to support both + usage models, two types of PT protocols are needed. One type of PT, + PT-TLS [RFC6876], 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. + + PT-EAP is an inner EAP [RFC3748] method designed to be used inside a + protected tunnel such as Tunnel EAP (TEAP) [RFC7170], EAP Flexible + Authentication via Secure Tunneling (EAP-FAST) [RFC4851], or EAP + Tunneled Transport Layer Security (EAP-TTLS) [RFC5281]. That is, an + outer EAP method is typically a TLS-based EAP method that first + establishes a protected tunnel by which other conversations, such as + other EAP methods (e.g., "inner" EAP methods) can ensue under the + tunnel protection. + +1.1. Prerequisites + + 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 [RFC5209]. The + reader is assumed to be thoroughly familiar with that document. + +1.2. Message Diagram Conventions + + 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. + + 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. + +1.3. Terminology + + This document reuses many terms defined in the NEA Requirements + document [RFC5209], such as "Posture Transport Client" and "Posture + Transport Server". The reader is assumed to have read that document + and understood it. + + + + +Cam-Winget & Sangster Standards Track [Page 3] + +RFC 7171 NEA PT-EAP May 2014 + + + 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 this specification. 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. + +1.4. Conventions Used in This Document + + 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 RFC 2119 [RFC2119]. + +1.5. Compatibility with Other Specifications + + 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 authors understand that 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. + +2. Use of PT-EAP + + 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 be used inside a TLS-based + EAP tunnel method that provides strong cryptographic authentication + (possibly server only), message integrity, and confidentiality + services. + +3. Definition of PT-EAP + + 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). + + This section describes and defines the PT-EAP method. First, it + provides a protocol overview. Second, it describes specific features + like version negotiation. Third, it gives a detailed packet + + + +Cam-Winget & Sangster Standards Track [Page 4] + +RFC 7171 NEA PT-EAP May 2014 + + + description. Finally, it describes how the tls-unique channel + binding [RFC5929] may be used to bind PA-TNC exchanges to the EAP + tunnel method, defeating man-in-the-middle (MITM) attacks such as the + Asokan attack [Asokan]. + +3.1. Protocol Overview + + PT-EAP has two phases that follow each other in strict sequence: + negotiation and data transport. + + The PT-EAP method begins with the negotiation phase. The NEA Server + starts this phase by sending a 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 Section 3.2. This is the + only message in the negotiation phase. + + 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 take turns sending a PB-TNC batch. The + data transport phase always ends with an EAP Response message from + the NEA Client to the NEA Server. The Data field of this message may + have zero length if the NEA Server has just sent the last PB-TNC + batch in the PB-TNC exchange. + + Note that the success of PT-EAP does not mean the overall + authentication (using the outer EAP tunnel method) will succeed. + Neither does the failure of PT-EAP mean that the overall + authentication will fail. Success of the overall authentication + depends on the policy configured by the administrator. + + 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. + + 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. + + + + + + + + +Cam-Winget & Sangster Standards Track [Page 5] + +RFC 7171 NEA PT-EAP May 2014 + + +3.2. Version Negotiation + + 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. + + 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 NEA Client MUST + abnormally terminate the EAP negotiation. + + 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. + + 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 [RFC5226]. + +3.3. PT-EAP Message Format + + This section provides a detailed description of the fields in a + PT-EAP message. For a description of the diagram conventions used + here, see Section 1.2. Since PT-EAP is an EAP method, the first four + fields (e.g., Code, Identifier, Length, and Type as shown in + Figure 1) in each message are mandated by and defined in EAP. The + other fields, e.g., Flags, Version, and Data are specific to PT-EAP. + + 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 ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: PT-EAP Message Format + + + +Cam-Winget & Sangster Standards Track [Page 6] + +RFC 7171 NEA PT-EAP May 2014 + + + Code + + The Code field is one octet and identifies the type of the EAP + message. The only values used for PT-EAP are: + + 1 Request + + 2 Response + + Identifier + + The Identifier field is one octet and aids in matching Responses + with Requests. + + Length + + The Length field is two octets and indicates the length in octets + of this PT-EAP message, starting from the Code field. + + Type + + 54 (EAP Method Type [RFC3748] assignment for PT-EAP). + + Flags + + +-+-+-+-+-+ + |S R R R R| + +-+-+-+-+-+ + + S: Start + + Indicates the beginning of a 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. + + R: Reserved + + This flag MUST be set to 0 and ignored upon receipt. + + Version + + This field is used for version negotiation, as described in + Section 3.2. + + + + + + + + +Cam-Winget & Sangster Standards Track [Page 7] + +RFC 7171 NEA PT-EAP May 2014 + + + Data + + Variable length data. This field is processed by the PB layer and + MUST include PB-TNC messages. For more information see PB-TNC + [RFC5793]. + + 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. + +3.4. Preventing MITM Attacks with Channel Bindings + + As described in the NEA Asokan Attack Analysis [RFC6813], 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, + that measures and attests to the configuration of the endpoint. + + 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 [RFC5929] from 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 of the NEA Client and NEA Server match and this is + confirmed by the EMA, then the posture sent by a trustworthy 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 MITM is forwarding posture. If they differ, an attack has been + detected, and the Posture Validator SHOULD fail its verification. + + Note that tls-unique, as opposed to invoking a mutual cryptographic + binding, is used as there is no keying material being generated by + PT-EAP (the method is defined to facilitate the transport of posture + data and is not an authentication method). However, the NEA Client + may host an EMA that can be used as the means to cryptographically + bind the tls-unique content that may be validated by the Posture + Validator interfacing with the EAP Server. The binding of the + tls-unique to the client authentication prevents the client's message + from being used in another context. This prevents a poorly + configured client from unintentionally compromising the NEA system. + Strong mutual authentication of the NEA Server and Client is still + REQUIRED to prevent the disclosure of possibly sensitive NEA Client + information to an attacker. + + + +Cam-Winget & Sangster Standards Track [Page 8] + +RFC 7171 NEA PT-EAP May 2014 + + +4. Security Considerations + + 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 that is capable of + protecting the PT-EAP protocol from many threats. Since the EAP + tunnel method will be specified separately, this section describes + the considerations on the EAP tunnel method but does not evaluate its + ability to meet those requirements. The security considerations and + requirements for NEA can be found in [RFC5209]. + +4.1. Trust Relationships + + 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. + +4.1.1. Posture Transport Client + + The Posture Transport Client is trusted by the Posture Broker Client + to: + + o Not disclose to unauthorized parties, fabricate, or alter the + contents of the PB-TNC batches received from the network. + + o Not observe, fabricate, or alter the PB-TNC batches passed down + from the Posture Broker Client for transmission on the network. + + o Transmit on the network any PB-TNC batches passed down from the + Posture Broker Client. + + o Provide configured security protections (e.g., authentication, + integrity, and confidentiality) for the Posture Broker Client's + PB-TNC batches sent on the network. + + o Expose the authenticated identity of the Posture Transport Server + to the Posture Broker Client. + + o Verify the security protections placed upon messages received from + the network to ensure the messages are authentic and protected + from attacks on the network. + + o Deliver to the Posture Broker Client the PB-TNC batches received + from the network so long as they are properly security protected. + + + +Cam-Winget & Sangster Standards Track [Page 9] + +RFC 7171 NEA PT-EAP May 2014 + + + o Provide a secure, reliable, "in-order delivery", full-duplex + transport for the Posture Broker Client's messages. + + Since the Posture Transport Server can not validate the + trustworthiness of the Posture Transport Client, the Posture + Transport Server should protect itself appropriately. + +4.1.2. Posture Transport Server + + The Posture Transport Server is trusted by the Posture Broker Server + to: + + o Not observe, fabricate, or alter the contents of the PB-TNC + batches received from the network. + + o Not observe, fabricate, or alter the PB-TNC batches passed down + from the Posture Broker Server for transmission on the network. + + o Transmit on the network any PB-TNC batches passed down from the + Posture Broker Server. + + o Ensure PB-TNC batches received from the network are properly + protected from a security perspective. + + o Provide configured security protections (e.g., authentication, + integrity, and confidentiality) for the Posture Broker Server's + messages sent on the network. + + o Expose the authenticated identity of the Posture Transport Client + to the Posture Broker Server. + + o Verify the security protections placed upon messages received from + the network to ensure the messages are authentic and protected + from attacks on the network. + + Since the Posture Transport Client can not validate the + trustworthiness of the Posture Transport Server, the Posture + Transport Client should protect itself appropriately. + +4.2. Threats and Countermeasures + + Beyond the trusted relationships assumed in Section 4.1, the PT-EAP + EAP method faces a number of potential security attacks that could + require security countermeasures. + + 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 + + + +Cam-Winget & Sangster Standards Track [Page 10] + +RFC 7171 NEA PT-EAP May 2014 + + + 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. + + Once the message is delivered to the Posture Broker Client or Posture + Broker Server, the Posture Brokers are trusted to properly and safely + process the messages. + +4.2.1. Message Confidentiality + + When PT-EAP messages are sent over unprotected network links or span + 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 an 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 carried by 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 that particular + sub-networks have more lenient policies. + + 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 bidirectional 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-FAST or EAP-TTLS, all of the contents of PB-TNC and + PA-TNC protocol messages are hidden from potential theft by + intermediaries lurking on the network. + +4.2.2. Message Fabrication + + 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 a PT-EAP message to tell a NEA + Server that the endpoint is totally infected. This could cause the + + + +Cam-Winget & Sangster Standards Track [Page 11] + +RFC 7171 NEA PT-EAP May 2014 + + + device to be blocked from accessing a critical resource, which would + be a denial of service. + + The EAP tunnel method carrying a 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. See + Section 5 for more details on the EAP tunnel requirements. + +4.2.3. Message Modification + + 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. + + PT-EAP leverages the EAP tunnel method (e.g., TEAP, EAP-FAST, or EAP- + TTLS) to provide strong authentication and integrity protections as a + countermeasure to this threat. The bidirectional authentication + prevents the attacker from acting as an active MITM to the protocol + that could be used to modify the message exchange. The strong + integrity protections offered by the TLS-based EAP tunnel method + allow 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 + needed to mitigate this threat. + +4.2.4. Denial of Service + + A variety of types of denial-of-service attacks are possible against + PT-EAP if the message exchange is 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. + + 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 bidirectional authentication will prevent unauthorized + parties from participating in a PT-EAP exchange. + + After the cryptographic authentication by the EAP tunnel method, the + session can be protected cryptographically to provide confidentiality + and source authenticity. Such protection prevents undetected + + + +Cam-Winget & Sangster Standards Track [Page 12] + +RFC 7171 NEA PT-EAP May 2014 + + + 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. + +4.2.5. NEA Asokan Attacks + + As described in Section 3.4 and in the NEA Asokan Attack Analysis + [RFC6813], 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. Section 3.4 and [RFC6813] provide a detailed + description of this attack and of the countermeasures that can be + employed against it. + + Because lying endpoint attacks are much easier than Asokan attacks + and an 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. If the tls-unique channel binding is + implemented, it must be verified before any other attestations are + evaluated. + +4.3. Candidate EAP Tunnel Method Protections + + This section discusses how PT-EAP is used within various EAP tunnel + methods to meet the PT requirements in Section 5. + + TEAP [RFC7170], EAP-FAST [RFC4851], and EAP-TTLS [RFC5281] make use + of TLS [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 the + 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. + + The phase two dialog may include authentication of the user by doing + other EAP methods or, in the case of EAP-TTLS, by using EAP or 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. + + + + +Cam-Winget & Sangster Standards Track [Page 13] + +RFC 7171 NEA PT-EAP May 2014 + + + With all these methods (e.g., TEAP [RFC7170], EAP-FAST [RFC4851], and + EAP-TTLS [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 methods. 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 method's keys is essential for + detection of conventional (non-NEA) Asokan attacks. + + TEAP [RFC7170] is the mandatory-to-implement EAP tunnel method. + +4.4. Security Claims for PT-EAP as per RFC 3748 + + This section summarizes the security claims for this specification, + as required by [RFC3748], Section 7.2: + + 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: No + Channel binding: No + +5. Requirements for EAP Tunnel Methods + + 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. + + + + + + +Cam-Winget & Sangster Standards Track [Page 14] + +RFC 7171 NEA PT-EAP May 2014 + + + TEAP [RFC7170] is a Standards Track EAP tunnel method that satisfies + NEA's requirements and is the mandatory-to-implement EAP tunnel + method. + + 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. + + RFC 5209 [RFC5209] includes the following requirement that is to be + applied during the selection of the EAP tunnel method(s) used in + conjunction with PT-EAP: + + 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. + + Note that mutual authentication could be achieved by a combination of + a strong authentication of one party (e.g., server authentication + while establishing the TLS-based tunnel) 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. + + 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. + + + + + +Cam-Winget & Sangster Standards Track [Page 15] + +RFC 7171 NEA PT-EAP May 2014 + + + The EAP tunnel method carrying PT-EAP MUST provide strong + cryptographic authentication, integrity, and confidentiality + protection to protect against NEA assessment message theft as + described in Section 4.2.1. The cryptographically protected EAP + tunnel ensures that all of the PA-TNC and PB-TNC protocol messages + are hidden from intermediaries wanting to steal NEA data. + + To support countermeasures against NEA Asokan attacks as described in + Section 3.4, the EAP tunnel method used with PT-EAP will need to + support generation of the tls-unique value to be used with the higher + layers of the NEA reference model. 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. + +6. Privacy Considerations + + 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 bidirectional + authentication is used), so the user's credentials are not directly + seen by the PT-EAP inner method. + + 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. + +7. IANA Considerations + + This section provides guidance to the Internet Assigned Numbers + Authority (IANA) regarding registration of values related to the + PT-EAP protocol, in accordance with BCP 26 [RFC5226]. + + The EAP Method type for PT-EAP has been assigned value 54, i.e., the + assignment for Type in Section 3.3. + + +-------+----------------------------+-----------+ + | Value | Description | Reference | + +-------+----------------------------+-----------+ + | 54 | EAP Method Type for PT-EAP | [RFC7171] | + +-------+----------------------------+-----------+ + + + + + +Cam-Winget & Sangster Standards Track [Page 16] + +RFC 7171 NEA PT-EAP May 2014 + + + This document also defines one new IANA top-level 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). + +7.1. Registry for PT-EAP Versions + + 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 also includes a reference to the RFC where the + version is defined. + + The following entries are defined in this document and are the + initial entries in the registry. Additional entries to this registry + are added by Standards Action, as defined in RFC 5226 [RFC5226]. + + +-------+------------------------+ + | Value | Defining Specification | + +-------+------------------------+ + | 0 | Reserved | + | 1 | [RFC7171] | + +-------+------------------------+ + +8. Acknowledgements + + Thanks to the Trusted Computing Group for contributing the initial + text upon which this document was based. + + The authors of this document 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, Stephen Hanna, 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, Joseph Salowey, Chris Salter, + Mauricio Sanchez, Dean Sheffield, Curtis Simonson, Jeff Six, Ned + Smith, Michelle Sommerstad, Joseph Tardo, Lee Terrell, Susan Thomson, + Chris Trytten, and John Vollbrecht. + + + + + + + +Cam-Winget & Sangster Standards Track [Page 17] + +RFC 7171 NEA PT-EAP May 2014 + + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. + Levkowetz, "Extensible Authentication Protocol (EAP)", RFC + 3748, June 2004. + + [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. + Tardo, "Network Endpoint Assessment (NEA): Overview and + Requirements", RFC 5209, June 2008. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + + [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute + (PA) Protocol Compatible with Trusted Network Connect + (TNC)", RFC 5792, March 2010. + + [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: + A Posture Broker (PB) Protocol Compatible with Trusted + Network Connect (TNC)", RFC 5793, March 2010. + + [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings + for TLS", RFC 5929, July 2010. + + [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, + "Tunnel Extensible Authentication Protocol (TEAP) Version + 1", RFC 7170, May 2014. + +9.2. Informative References + + [Asokan] Asokan, N., Niemi, V., Nyberg, K., and Nokia Research + Center, Finland, "Man-in-the-Middle Attacks in Tunneled + Authentication Protocols", Nov 2002, + <http://eprint.iacr.org/2002/163.pdf>. + + [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The + Flexible Authentication via Secure Tunneling Extensible + Authentication Protocol Method (EAP-FAST)", RFC 4851, May + 2007. + + + +Cam-Winget & Sangster Standards Track [Page 18] + +RFC 7171 NEA PT-EAP May 2014 + + + [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication + Protocol Tunneled Transport Layer Security Authenticated + Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. + + [RFC6813] Salowey, J. and S. Hanna, "The Network Endpoint Assessment + (NEA) Asokan Attack Analysis", RFC 6813, December 2012. + + [RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture + Transport Protocol over TLS (PT-TLS)", RFC 6876, February + 2013. + +Authors' Addresses + + Nancy Cam-Winget + Cisco Systems + 80 West Tasman Drive + San Jose, CA 95134 + US + + EMail: ncamwing@cisco.com + + + Paul Sangster + Symantec Corporation + 6825 Citrine Drive + Carlsbad, CA 92009 + US + + EMail: paul_sangster@symantec.com + + + + + + + + + + + + + + + + + + + + + + +Cam-Winget & Sangster Standards Track [Page 19] + |