RFC 7171

PT-EAP: Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP) Tunnel Methods

📅 published May 2014, from ietf

PT-EAP: Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP) Tunnel Methods 🎀

okay bestie, let's do the vibe check first 💖 this is RFC 7171 from the IETF, and it's a Standards Track document, so it's the real deal, not a side quest 👑. It was written by N. Cam-Winget from Cisco Systems and P. Sangster from Symantec Corporation. It came out in May 2014 with ISSN 2070-1721, and its header doesn't list any Obsoletes or Updates entries, so it doesn't replace or patch anything else 🦋

Abstract 🌸

so PT-EAP is a Posture Transport (PT) protocol built on top of the Extensible Authentication Protocol (EAP) 🧚 it's designed to be used only inside an EAP tunnel method that's protected by Transport Layer Security (TLS) 🔐 the doc also talks about where PT-EAP is meant to fit in, aka its intended applicability ✨

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 got public review and was approved for publication by the Internet Engineering Steering Group (IESG). more info on Internet Standards is in Section 2 of RFC 5741 📚

info about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc7171 🌈

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) as in effect on the date of publication. please read these carefully, because they explain 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 they're provided without warranty as described in the Simplified BSD License 🍓

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 in charge of moving Posture Broker (PB-TNC [RFC5793]) batches, which often carry 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 so the messages stay safe from all sorts of threats from hostile intermediaries 🛡️

NEA protocols are meant to be used both for pre-admission assessment of endpoints that are joining the network and for assessment of endpoints already on the network 👀 to cover both usage models, two types of PT protocols are needed. one type, PT-TLS [RFC6876], runs after the endpoint has an assigned IP address, layering on top of the IP protocol to carry a NEA exchange. the other type runs before the endpoint gets any access to the IP network. this specification defines PT-EAP, the PT protocol used to assess endpoints before they get network access 🦋

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]. basically, an outer EAP method is usually a TLS-based EAP method that first sets up a protected tunnel, and then other conversations, like other EAP methods (e.g., "inner" EAP methods), can happen under the tunnel's protection 🫧

1.1. Prerequisites 📖

this document doesn't 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 shows the format and size of each field in bits. implementations MUST send the bits in each diagram exactly as they are shown, going 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 🌊

the bit field (e.g., flag) values are described by 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 lots of terms defined in the NEA Requirements document [RFC5209], like "Posture Transport Client" and "Posture Transport Server". the reader is assumed to have read that document and understood it 🤓

when defining the PT-EAP method, this specification doesn't use the terms "EAP peer" and "EAP authenticator". instead, it uses "NEA Client" and "NEA Server", since those are considered 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 that everyone agrees on 🌈 so 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. iconic teamwork, honestly 🫶

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 doesn't have to do that itself. 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, letting them 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 gives a protocol overview. second, it describes specific features like version negotiation. third, it gives a detailed packet description. finally, it describes how the tls-unique channel binding [RFC5929] may be used to bind PA-TNC exchanges to the EAP tunnel method, which defeats man-in-the-middle (MITM) attacks such as the Asokan attack [Asokan] 🦋🔥

3.1. Protocol Overview ✨

okay so PT-EAP has two phases that always go in strict order 💅: negotiation first, then data transport.

The method kicks off with negotiation. The NEA Server starts it by sending a PT-EAP Start message, which is an EAP Request message of type PT-EAP with the S (Start) flag set. The NEA Server also sets the Version field (more on that in Section 3.2). This is literally the only message in the negotiation phase 🌸

Data transport is the only phase where PB-TNC batches are allowed to be exchanged 🫶. It always starts with the NEA Client sending a PB-TNC batch to the NEA Server, and then the NEA Client and NEA Server take turns sending PB-TNC batches. The phase always wraps up with an EAP Response message from the NEA Client to the NEA Server. The Data field of that message may have zero length if the NEA Server has just sent the last PB-TNC batch in the exchange.

Ngl this next part is a big deal ⚠️. PT-EAP succeeding does not mean the overall authentication (the one using the outer EAP tunnel method) will succeed. And PT-EAP failing doesn't mean overall authentication fails either. Whether the overall thing passes depends on the policy the administrator configured.

At the end of PT-EAP, the NEA Server tells the EAP tunnel method whether things worked out. Some tunnel methods explicitly confirm that the inner method succeeded, and others don't. That part is out of scope for the PT-EAP spec 🙈. Same deal as before: PT-EAP success doesn't imply overall success, and PT-EAP failure doesn't imply overall failure. That 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 it. Depending on what the EAP tunnel method can do, this may also mean terminating the tunnel method too.

3.2. Version Negotiation 🎀

okay this is the version handshake, and it happens in the first PT-EAP message from the NEA Server (the Start message) and the first PT-EAP message from the NEA Client (its response to Start). The NEA Server MUST set the Version field in the Start message to the highest PT-EAP version it supports and is willing to accept 📈.

The NEA Client picks the version for the exchange and puts it in the Version field of its response to Start. The NEA Client SHOULD choose the value the NEA Server sent, as long as it supports it. However, the NEA Client MAY set Version to something lower than the value the NEA Server sent (for example, if it only supports older PT-EAP versions). If the NEA Client only supports PT-EAP versions greater than the value the NEA Server sent, the NEA Client MUST abnormally terminate the EAP negotiation 💀.

If the version the NEA Client sent isn't acceptable to the NEA Server, the NEA Server MUST terminate the PT-EAP session immediately. Otherwise, the version the NEA Client sent is the version of PT-EAP that MUST be used. Both the NEA Client and the NEA Server MUST set the Version field to that chosen version number in all subsequent PT-EAP messages in this exchange 👑.

This spec defines version 1 of PT-EAP. Version 0 is reserved and MUST never be sent. New versions (values 2-7) may be defined by Standards Action, as defined in [RFC5226].

3.3. PT-EAP Message Format 📦

This section gives a detailed rundown of the fields in a PT-EAP message. For the diagram conventions, see Section 1.2. Since PT-EAP is an EAP method, the first four fields (Code, Identifier, Length, and Type, as shown in Figure 1) are mandated by and defined in EAP. The other fields (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

Code

The Code field is one octet and tells you what type of EAP message this is. The only values used for PT-EAP are:

1  Request
2  Response

Identifier

This one is one octet and helps match Responses with Requests 🧩.

Length

This is two octets and shows the length in octets of this PT-EAP message, counting from the Code field.

Type

54 (EAP Method Type [RFC3748] assignment for PT-EAP). That's PT-EAP's official number 🦋.

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

Used for version negotiation, as described in Section 3.2.

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 the unhealthy machine can get 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, the Posture Broker on an EMA-equipped endpoint needs to pass the tls-unique channel binding [RFC5929] from PT-EAP's tunnel method over to the EMA. That value can then be included in the EMA's attestation, so the responsible Posture Validator can confirm it 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 the EMA confirms this, then the posture sent by a trustworthy EMA (and so the NEA Client) comes from the same endpoint as the client side of the TLS connection, since the endpoint knows the tls-unique value. That means 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 is used instead of invoking a mutual cryptographic binding, because PT-EAP doesn't generate any keying material (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, which the Posture Validator interfacing with the EAP Server may then validate. Binding tls-unique to client authentication keeps the client's message from being used in another context. This stops a poorly configured client from accidentally 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.

4. Security Considerations 🛡️

This section covers the major threats and countermeasures PT-EAP provides. As discussed throughout the document, the PT-EAP method is designed to run inside an EAP tunnel method that can protect 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 🤝

Okay, so to figure out where security countermeasures are needed, we first need to look at where the NEA architecture expects trust between the processing elements of PT-EAP traffic flowing inside an EAP tunnel. The sub-sections below cover the trust properties for each part of the NEA reference model that's directly involved in processing that traffic.

4.1.1. Posture Transport Client

The Posture Transport Client is trusted by the Posture Broker Client to:

  • Never leak, make up, or mess with the contents of the PB-TNC batches it receives from the network.
  • Never spy on, fake, or change the PB-TNC batches passed down from the Posture Broker Client for sending on the network.
  • Actually transmit on the network any PB-TNC batches passed down from the Posture Broker Client.
  • Provide the configured security protections (for example, authentication, integrity, and confidentiality) for the Posture Broker Client's PB-TNC batches sent on the network.
  • Expose the authenticated identity of the Posture Transport Server to the Posture Broker Client.
  • Verify the security protections on messages received from the network, so it knows they're authentic and protected from attacks on the network.
  • Deliver the PB-TNC batches received from the network to the Posture Broker Client, as long as they're properly security protected.
  • 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 ✨

okay so the Posture Transport Server is trusted by the Posture Broker Server to: 💅

  • Not observe, fabricate, or alter the contents of the PB-TNC batches received from the network. 🙈
  • Not observe, fabricate, or alter the PB-TNC batches passed down from the Posture Broker Server for transmission on the network. 🔒
  • Transmit on the network any PB-TNC batches passed down from the Posture Broker Server. 📡
  • Ensure PB-TNC batches received from the network are properly protected from a security perspective. 🛡️
  • Provide configured security protections (e.g., authentication, integrity, and confidentiality) for the Posture Broker Server's messages sent on the network. 💖
  • Expose the authenticated identity of the Posture Transport Client to the Posture Broker Server. 🫶
  • Verify the security protections placed upon messages received from the network to ensure the messages are authentic and protected from attacks on the network. 👑

bestie, the Posture Transport Client can't actually validate how trustworthy the Posture Transport Server is, so the Posture Transport Client should protect itself appropriately. 🥺

4.2. Threats and Countermeasures 🦋

beyond the trust relationships we just covered in Section 4.1, the PT-EAP EAP method has a bunch of potential security attacks that might need countermeasures. 😭

generally, the PT protocol is in charge of giving strong security protections to all of the NEA protocols, so any threat to PT's ability to protect NEA protocol messages could be seriously damaging for deployments. 💀 for the PT-EAP method, most of the cryptographic security comes from the outer EAP tunnel method, and PT-EAP gets encapsulated inside that protected tunnel. so this section highlights the cryptographic requirements the EAP tunnel method carrying PT-EAP has to meet in order to satisfy the NEA PT requirements. it's giving layers 🧁

once a message is delivered to the Posture Broker Client or Posture Broker Server, the Posture Brokers are trusted to process the messages properly and safely. ✨

4.2.1. Message Confidentiality 🌸

when PT-EAP messages travel over unprotected network links or go through local software stacks that aren't trusted, their contents can be stolen by someone in the middle. 😱 that theft could mean info gets recorded for future use or analysis by an adversary. messages seen by eavesdroppers could reveal weaknesses in the endpoint's security, or system fingerprinting info that makes it easier for the attacker to launch attacks that are more likely to work against the endpoint. the eavesdropper might also learn about the endpoint or network policies, and that info, either on its own or combined with other stuff, might count as sensitive. for example, if PT-EAP is carried by an EAP tunnel method that doesn't provide confidentiality protection, an adversary could look at the PA-TNC attributes inside the PB-TNC batch and figure out that the endpoint is missing patches or that certain sub-networks have more lenient policies. 🙃

to protect against NEA assessment message theft, the EAP tunnel method carrying PT-EAP must provide strong cryptographic authentication, integrity, and confidentiality protection. using bidirectional authentication in the EAP tunnel method carrying PT-EAP makes sure that only properly authenticated and authorized parties can be involved in an assessment message exchange. 🔐 when PT-EAP is carried inside a cryptographically protected EAP tunnel method like EAP-FAST or EAP-TTLS, all of the contents of the PB-TNC and PA-TNC protocol messages are hidden from theft by intermediaries lurking on the network. 🫣

4.2.2. Message Fabrication 🎀

attackers on the network, or already inside the NEA system, could slip in fabricated PT-EAP messages to trick the system or cause a denial of service against parts of an assessment. 😤 for example, an adversary could try to insert a PT-EAP message telling a NEA Server that the endpoint is totally infected. that could get the device blocked from accessing a critical resource, which would be a denial of service. not cute. 💔

the EAP tunnel method carrying a PT-EAP method needs to provide strong security protections for the whole message exchange over the network. those protections stop an intermediary from inserting fake messages into the assessment. see Section 5 for more details on the EAP tunnel requirements. 📖

4.2.3. Message Modification 🦋

this attack could let an active attacker who can intercept a message change a PT-EAP message or a transported PA-TNC attribute to a value they want, which could make it easier to compromise an endpoint. 🫠 if message recipients can't detect whether a received message has the same content as what was originally sent, active attackers can quietly change the attribute exchange. yikes. 😬

PT-EAP leans on the EAP tunnel method (for example TEAP, EAP-FAST, or EAP-TTLS) to provide strong authentication and integrity protections as the countermeasure to this threat. the bidirectional authentication stops the attacker from acting as an active man-in-the-middle on the protocol, which is what could be used to modify the message exchange. the strong integrity protections offered by the TLS-based EAP tunnel method let PT-EAP message recipients detect alterations by other types of network-based adversaries. 🙌 because PT-EAP doesn't 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 🚨

there are a bunch of different denial-of-service attacks that can hit PT-EAP if the message exchange is left unprotected while it travels over the network. the Posture Transport Client and Posture Transport Server are trusted not to take part in denial of service against the assessment session, so the threats are coming from the network. 🌐

the PT-EAP method mostly relies on the outer EAP tunnel method to provide strong authentication (of at least one party), and deployers are expected to use other EAP methods to authenticate the other party (usually the client) inside the protected tunnel. using protected bidirectional authentication will stop unauthorized parties from joining a PT-EAP exchange. 🚫

once the EAP tunnel method has done its cryptographic authentication, the session can be protected cryptographically to provide confidentiality and source authenticity. that protection prevents undetected modification that could create a denial-of-service situation. 🛡️ however, an adversary can still alter the message flows, so that each message gets rejected by the recipient because it fails the integrity checking. annoying, but still a thing. 😩

4.2.5. NEA Asokan Attacks 🕵️‍♀️

as described in Section 3.4 and in the NEA Asokan Attack Analysis [RFC6813], a sophisticated man-in-the-middle attack can be mounted against NEA systems. the attacker forwards PA-TNC messages from a healthy machine through an unhealthy one, so the unhealthy machine can get network access anyway. 🙀 Section 3.4 and [RFC6813] give a detailed description of this attack and of the countermeasures that can be used against it. 📚

lying endpoint attacks are way easier than Asokan attacks, and an effective countermeasure against lying endpoint attacks is using an External Measurement Agent (EMA). so countermeasures against an Asokan attack aren't necessary unless an EMA is in use. 🙄 but PT-EAP implementers might 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. verify first, slay later. ✅

4.3. Candidate EAP Tunnel Method Protections 🧚

this section talks about how PT-EAP gets used inside various EAP tunnel methods to meet the PT requirements in Section 5. 💜

TEAP [RFC7170], EAP-FAST [RFC4851], and EAP-TTLS [RFC5281] all 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 gets set up between the NEA Client and NEA Server. in the second phase, that tunnel is used to pass other information along. PT-EAP requires that establishing this tunnel include at least an authentication of the NEA Server by the NEA Client. 🔑

the phase two dialog might include authentication of the user by running 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, so the NEA assessment lives inside an encrypted and integrity-protected transport. 🌈

with all of these methods (for example TEAP [RFC7170], EAP-FAST [RFC4851], and EAP-TTLS [RFC5281]), a cryptographic key is derived from the authentication, and that key may be used to secure later transmissions. each of these methods uses at least NEA Server authentication with an X.509 certificate. inside each EAP tunnel method there will be a set of inner EAP methods. those inner methods may do extra security handshakes, including more granular authentications or exchanges of integrity info (like PT-EAP). at some point after each inner EAP method concludes, some of the methods will export the established secret keys to the outer tunnel method. the outer method is expected to cryptographically mix these keys into any keys it's currently using to protect the session, and then do a final operation to check whether both parties ended up with the same mixed key. this cryptographic binding of the inner method results to the outer method's keys is essential for detecting 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 ✨

Okay bestie, this section is basically the checklist for the outer EAP tunnel method 🫶 PT-EAP's inner method leans on that outer tunnel for most of its security, so this part repeats the PT requirements that the IETF standard EAP tunnel method MUST meet for use with PT-EAP 💅

TEAP [RFC7170] is the one. It's a Standards Track EAP tunnel method, it satisfies NEA's requirements, and it's the mandatory-to-implement EAP tunnel method 👑

The security requirements in this spec MUST be implemented in any product claiming to be PT-EAP compliant 🔥 Whether a particular deployment actually uses these protections is a deployment issue. A customer may choose to skip potential deployment issues or performance penalties from cryptography when the required protection is already achieved another way (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 that into their decisions 🧚

RFC 5209 [RFC5209] has a requirement you have to check when picking the EAP tunnel method(s) to use 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.

Mutual authentication can be achieved by combining two things: a strong authentication of one party (e.g., server authentication while the TLS-based tunnel is being set up) by the EAP tunnel method, plus a second authentication of the other party (e.g., client authentication inside the protected tunnel) by another EAP method that runs before PT-EAP 🦋

Having the Posture Transport Client always authenticate the Posture Transport Server gives the NEA Client assurance that the NEA Server is legit (not a rogue or MITM) before it discloses secret or potentially privacy-sensitive info about what's running or configured on the endpoint 😭 The NEA Server's policy may allow the NEA Client's authentication to be delayed until a suitable protected channel exists, so non-cryptographic NEA Client credentials (e.g., username/password) can be used. Whether the channel uses mutual or server-side-only authentication, the resulting channel needs to provide strong integrity and confidentiality protection for its contents. Those protections are 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 🔐

The EAP tunnel method carrying PT-EAP MUST provide strong cryptographic authentication, integrity, and confidentiality protection to guard against NEA assessment message theft, as described in Section 4.2.1. This is the part that's giving main character energy: the cryptographically protected EAP tunnel hides all of the PA-TNC and PB-TNC protocol messages from intermediaries who want to steal NEA data 💜

To support countermeasures against NEA Asokan attacks (see Section 3.4), the EAP tunnel method used with PT-EAP will need to support generating the tls-unique value for use 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 🎀

Here's the tea: PT-EAP's whole job is to act as a secure transport for PB-TNC over a network before the endpoint has been admitted to that network 🚪 As a transport protocol, PT-EAP doesn't directly use or need to know any personally identifiable information (PII). PT-EAP will usually be used alongside other EAP methods that handle user authentication (if bidirectional authentication is used), so the PT-EAP inner method never directly sees the user's credentials 🙈

PT-EAP doesn't provide cryptographic protection for the PB-TNC batches itself, but it's designed to run inside an EAP tunnel method that gives strong authentication, integrity, and confidentiality. So deployers really need to lean on those protections to stop PII that might be sitting inside PA-TNC or PB-TNC within the PT-EAP payload from getting disclosed 🫶

7. IANA Considerations 📋

This section gives guidance to the Internet Assigned Numbers Authority (IANA) about registering values related to the PT-EAP protocol, following BCP 26 [RFC5226] 💖

The EAP Method type for PT-EAP has been assigned value 54, which is the assignment for Type in Section 3.3 🎉

            +-------+----------------------------+-----------+
            | Value |        Description         | Reference |
            +-------+----------------------------+-----------+
            |   54  | EAP Method Type for PT-EAP | [RFC7171] |
            +-------+----------------------------+-----------+

This document also defines one new IANA top-level registry: "PT-EAP Versions" 🌈 This section explains how that registry works. Only eight (8) values are available in this registry, so a high bar is set for new assignments. The only way to register new values is through Standards Action (via an approved Standards Track RFC) 💀

7.1. Registry for PT-EAP Versions

The name of this registry is "PT-EAP Versions". Each entry has a decimal integer value between 1 and 7 identifying the version, plus a reference to the RFC where that version is defined ✨

The following entries are defined in this document and are the initial entries in the registry. Any additional entries 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 this document was based on 🙌

The authors would like to shoutout the following people, who contributed to or gave substantial input on this document or its predecessors: 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 🌟

9. References 📚

9.1. Normative References

These are the references the spec needs to be read properly 🧠

   [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

These ones are good background reading, not required 🌷

   [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.

   [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

That's the whole spec, bestie! 🌈✨ Nancy and Paul really did the most 👑💅

📦 where this page comes from