RFC 6876
A Posture Transport Protocol over TLS (PT-TLS)
RFC 6876: A Posture Transport Protocol over TLS (PT-TLS) 🎀
Okay bestie, let's start with the basics 💅
- RFC number: 6876
- Title: A Posture Transport Protocol over TLS (PT-TLS)
- Authors: P. Sangster (Symantec Corporation), N. Cam-Winget (Cisco Systems), and J. Salowey (Cisco Systems)
- Category: Standards Track
- Stream: Internet Engineering Task Force (IETF)
- ISSN: 2070-1721
- Date: February 2013
- Obsoletes / Updates: the title block doesn't list either one 🤷♀️
Abstract ✨
So the TL;DR is that this doc specifies PT-TLS, a TLS-based Posture Transport (PT) protocol. It carries the Network Endpoint Assessment (NEA) message exchange inside a Transport Layer Security (TLS) secured tunnel. Basically, the assessment stuff gets wrapped in TLS so it stays protected 🔒🫶
Status of This Memo 📋
This is an Internet Standards Track document. 🌸
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 5741.
For the current status of this document, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6876.
Copyright Notice ©️
Copyright (c) 2013 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. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License. 📜
Table of Contents 🗂️
1. Introduction ....................................................3
1.1. Prerequisites ..............................................4
1.2. Message Diagram Conventions ................................4
1.3. Conventions Used in This Document ..........................4
1.4. Compatibility with Other Specifications ....................4
2. Design Considerations ...........................................5
2.1. Benefits of TCP/IP Connectivity ............................5
2.2. Leveraging Proven TLS Security .............................6
2.3. TLV-Based Message Encapsulation ............................6
2.4. No Change to Base TLS Protocol .............................6
3. PT-TLS Protocol .................................................7
3.1. Initiating a PT-TLS Session ................................8
3.1.1. Issues with Server-Initiated PT-TLS Sessions ........8
3.1.2. Establish or Re-Use Existing PT-TLS Session .........9
3.2. TCP Port Usage .............................................9
3.3. Preventing MITM Attacks with Channel Bindings ..............9
3.4. PT-TLS Message Flow .......................................10
3.4.1. Assessment Triggers ................................10
3.4.2. PT-TLS Message Exchange Phases .....................11
3.4.2.1. TLS Setup Phase ...........................12
3.4.2.2. PT-TLS Negotiation Phase ..................13
3.4.2.3. PT-TLS Data Transport Phase ...............14
3.4.3. TLS Requirements ...................................14
3.5. PT-TLS Message Format .....................................15
3.6. IETF Namespace PT-TLS Message Types .......................18
3.7. PT-TLS Version Negotiation ................................20
3.7.1. Version Request Message ............................21
3.7.2. Version Response Message ...........................22
3.8. Client Authentication Using SASL ..........................22
3.8.1. SASL Client Authentication Requirements ............23
3.8.2. SASL in PT-TLS Overview ............................24
3.8.3. SASL Authentication Flow ...........................24
3.8.4. Aborting SASL Authentication .......................25
3.8.5. Linkages to SASL Framework .........................25
3.8.5.1. SASL Service Name .........................25
3.8.5.2. SASL Authorization Identity ...............25
3.8.5.3. SASL Security Layer .......................25
3.8.5.4. Multiple Authentications ..................25
3.8.6. SASL Channel Bindings ..............................25
3.8.7. SASL Mechanisms ....................................26
3.8.8. SASL Mechanism Selection ...........................26
3.8.9. SASL Authentication Data ...........................27
3.8.10. SASL Result .......................................28
3.9. Error Message .............................................29
4. Security Considerations ........................................32
4.1. Trust Relationships .......................................32
4.1.1. Posture Transport Client ...........................33
4.1.2. Posture Transport Server ...........................34
4.2. Security Threats and Countermeasures ......................35
4.2.1. Message Theft ......................................35
4.2.2. Message Fabrication ................................36
4.2.3. Message Modification ...............................36
4.2.4. Denial of Service ..................................37
4.2.5. NEA Asokan Attacks .................................37
4.2.6. Trust Anchors ......................................38
5. Privacy Considerations .........................................38
6. IANA Considerations ............................................38
6.1. Designated Expert Guidelines ..............................39
6.2. Registry for PT-TLS Message Types .........................40
6.3. Registry for PT-TLS Error Codes ...........................41
7. Acknowledgments ................................................41
8. References .....................................................42
8.1. Normative References ......................................42
8.2. Informative References ....................................431. Introduction ✨
The NEA architecture [RFC5209] defines a system for communicating posture between a client, where it gets collected, and a server, where it gets assessed. Posture is the configuration and/or status of hardware or software on an endpoint, as it relates to an organization's security policy. This document specifies PT-TLS, a TLS-based Posture Transport (PT) protocol protected by a TLS channel. 🦋
NEA protocols are meant for two things: pre-admission assessment of endpoints joining the network, and assessment of endpoints already on the network. To cover both, two different types (or bindings) of PT protocols are needed, one for before the endpoint has an assigned IP address and other network-layer info, and one for after. This specification focuses on the PT protocol for endpoints already on the network, so it can use TCP/IP-based transport protocols. NEA has its own protocol for the pre-IP case, called PT-EAP [PT-EAP], which handles assessment before the endpoint has an assigned IP address. 🌈
The Posture Transport protocol in the NEA architecture [RFC5209] carries Posture Broker (PB-TNC [RFC5793]) batches over the network, and those batches often contain Posture Attributes (PA-TNC [RFC5792]). It travels between the Posture Transport Client component of the NEA Client and the Posture Transport Server component of the NEA Server. 💜
The PT protocol also comes with strong security protections, so the exchanged messages stay safe from a whole bunch of threats posed by hostile intermediaries. Very important, very iconic 👑
1.1. Prerequisites 📚
This document doesn't define an architecture or reference model. Instead, it defines one binding of the PT protocol that works within the reference model described in the NEA Overview and Requirements specification [RFC5209]. The reader is assumed to be thoroughly familiar with [RFC5209]. The NEA working group checked the functionality in this specification against the requirements in [RFC5209] and found that each applicable requirement was addressed. Slay 💅
1.2. Message Diagram Conventions 🍓
This specification defines the syntax of PT-TLS 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're shown: go from top to bottom, and within each line (which represents a 32-bit quantity), go from left to right. Multi-byte fields that represent numeric values must be sent in network (big endian) byte order. 🧚
Bit field values (like a flag) are described by the position of the bit within the field. Those bit positions are numbered from the most significant bit down to the least significant bit, so a one-octet field with only bit 0 set has the value 0x80. Bit 0 is the boss bit, obviously 😭
1.3. Conventions Used in This Document 🫧
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. These are the official requirement words, so whenever you see them in caps, they're doing real work. 🔥
1.4. Compatibility with Other Specifications 🤝
One of the goals of the NEA effort is to deliver a single set of endpoint assessment standards that everybody agrees on. Because of that, 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. Big unity energy ✨
2. Design Considerations 🧠
This section talks about some of the key design considerations for the PT protocol. This document specifies the PT binding for use when doing an assessment or reassessment after the endpoint has been admitted to the network and can use TCP/IP to talk to the NEA Server. If the endpoint doesn't yet have TCP/IP-layer access to the NEA Server (and vice versa), the endpoint can use the PT-EAP (Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP) Tunnel Methods) protocol for the assessment. 🎀
Since the endpoint has TCP/IP access to the NEA Server (possibly on a restricted part of the network), the NEA Client and NEA Server can set up (or reuse) a reliable TCP/IP connection to do the assessment. That connection gives the assessment a relatively high-performance, reliable channel that can handle multiple roundtrip message exchanges in a full-duplex manner. Those connection properties are super different from what you get when an endpoint first joins the network (for example, during an 802.1X-based assessment). So the design in this specification takes a different path, to get the most out of the underlying TCP/IP connection. Main character design choices, no cap 👑
2.1. Benefits of TCP/IP Connectivity 🦋
okay so the PT protocol over TLS is typically able to give the NEA Client and NEA Server way higher quality of service and flexibility than PT-EAP 💅. ngl, there can be some added risks when the endpoint is on the network before its initial assessment (if no admission time assessment was performed) 😬. Because of those risks, doing an EAP-based assessment during admission and then reassessing over TCP/IP may be the move in some environments 🫶.
Some of the perks of having a TCP/IP-based transport during an assessment include:
- Full-Duplex Connectivity - used to support asynchronous initiation of posture exchanges within a single TLS connection (e.g., triggered by alerts of posture or policy changes) 🔥
- High Bandwidth - potentially much higher bandwidth than other transports (e.g., EAP), allowing more in-band data (e.g., remediation, verbose posture information) 📈
- Large Messages - ability to send very large Posture Attribute messages without directly fragmenting them (underlying carrier protocol may introduce fragmentation) 🧚
- Bidirectional - NEA Client and NEA Server can initiate an assessment or reassessment 🔁
- Multiple Roundtrips - NEA Client and NEA Server can exchange numerous messages without fear of infrastructure timeouts. However, the entire exchange should be kept as brief as possible if the user has to wait for its completion ⏳
2.2. Leveraging Proven TLS Security 🔐
okay this one is my fave 🌈 All PT protocol bindings must be capable of providing strong authentication, integrity, and confidentiality protection for the PB-TNC batches. Instead of inventing a brand-new protocol over TCP/IP to get that protection, this specification requires the use of Transport Layer Security [RFC5246] to secure the connection. TLS was picked because it's a widely deployed protocol with parallel protections to a number of the EAP tunnel methods, and it meets all of the security requirements 💖. no need to reinvent the wheel, periodt 💅
2.3. TLV-Based Message Encapsulation 🎀
The design of the PT-TLS protocol is based on a type-length-value (TLV)-oriented protocol message. Each one identifies the type of message, the message's length, and a potentially variable-length payload value. The TLV-oriented encoding was chosen to match the Internet standard PA-TNC and PB-TNC protocols. Because the PA-TNC, PB-TNC, and PT-TLS protocols are typically implemented inside the same process space, a common set of message-parsing code can be used, which is so clean 🧼. Creating debugging tools is also simplified by the common encoding methodologies 🛠️.
TLV-based encoding was used in each of the NEA protocols partly because it enables a very space-efficient representation on the network, and it's simpler to parse than some other encodings. That's a big win for lower-powered (or battery constrained) devices 🔋✨.
2.4. No Change to Base TLS Protocol 🦄
During the design of the PT-TLS protocol, several approaches were considered, each with different costs and benefits 🤔. Several of those approaches involved integrating the PT protocol into the TLS handshake protocol. Because the PT protocol requires the underlying TLS carrier to provide security protections, the PT protocol couldn't operate before the cipher suites were negotiated and in use 🙈.
One option was to integrate into the TLS handshake protocol after the ChangeCipherSpec phase, which would let the PT message be protected. The upside is that the assessment protocol could operate below the application protocols, making it easier to integrate into applications. However, this change would require some extensions to the TLS handshake protocol standards and to existing widely deployed TLS implementations. So it wasn't clear the cost was worth it, especially because that application independence can also be offered by a shim library between the application and TLS library that provides the PT protocol encapsulation/decapsulation 🤷♀️.
The other general approach was to have PT-TLS layer on top of TLS as an application protocol (using the standard application_data ContentType). The big advantage here is that existing TLS software could be used 🙌. The catch is that the PB-TNC traffic would need to be encapsulated/decapsulated by a new PT-TLS protocol layer before being passed to the TLS library. That didn't seem like a huge deal, since PB-TNC is architected to layer on PT anyway 💜.
After weighing the options, it was determined that layering the PT protocol on top of the TLS protocol, without requiring current TLS protocol implementations to change, met all the requirements. It also offered the best path toward rapid adoption and deployment 🚀. So the following sections describe a PT protocol that is carried on top of TLS. Let's gooo 🍓
3. PT-TLS Protocol 🧚
This section specifies the PT-TLS protocol, a Posture Transport (PT) protocol carried by the Transport Layer Security (TLS) protocol over a TCP/IP network. As the figure below shows, this protocol runs directly on top of TLS as an application. That means PT-TLS is encapsulated within the TLS Record Layer protocol using the standard ContentType for applications (application_data) 🌸.
+---------------------------------------------------------------+
| TLV Encapsulation of PB-PA message |
+---------------------------------------------------------------+
| TLS |
+---------------------------------------------------------------+
| TCP |
+---------------------------------------------------------------+
Figure 1. PT-TLS Layering Model3.1. Initiating a PT-TLS Session 🚀
The PT-TLS protocol may be initiated by a Posture Transport Client or a Posture Transport Server. This flexibility supports different use cases! For example, a Posture Transport Client that wants to trigger a NEA assessment to check whether its security posture is good can start up a PT-TLS session and request a posture assessment 🧐. On the other hand, when an endpoint requests access to a protected network or resource, a Posture Transport Server can start up a PT-TLS session and perform a posture assessment before deciding whether to grant access 🚪.
The party that initiates a PT-TLS session is known as the "PT-TLS Initiator". The other party in the session (the one that receives the request to open a PT-TLS session) is known as the "PT-TLS Responder" 🤝.
3.1.1. Issues with Server-Initiated PT-TLS Sessions 😬
In order for a NEA Server to establish a PT-TLS session, the NEA Client needs to be listening for a connection request on a TCP port known by the NEA Server. In many deployments, the security policies of an endpoint (e.g., firewall software) or of a network (e.g., firewall devices) are designed to minimize the number of open inbound TCP/UDP ports available to the network, which reduces the potential attack footprint. This is one issue that makes it hard for a NEA Server to initiate a PT-TLS session 🧱.
Another issue with this scenario involves X.509 certificates 📜. When the NEA Server creates a TLS session to the NEA Client, the NEA Client is effectively acting as the TLS server during the TLS protocol exchange. This means the NEA Client would typically need to possess an X.509 certificate to protect the initial portion of the TLS handshake. In situations where the NEA Server initiates the creation of the TLS session, both the NEA Client and NEA Server MUST possess X.509 certificates to fully authenticate the session. For many deployments, provisioning X.509 certificates to all NEA Clients has scalability and cost issues. Therefore, it is recommended that the NEA Client not listen for connection requests from the NEA Server, but instead establish and maintain a TLS session to the NEA Server proactively. That way, either party can initiate an assessment using the preexisting TLS session as required 💫.
In most cases, the traditional methods of server certificate ID validation will not apply when the NEA Server initiates the connection. In this case, the NEA Client and Server need to follow the certificate path validation rules in RFC 5280 [RFC5280]. In addition, each side needs to be able to authorize its peer based upon matching Subject and SubjectAltName fields for certificates issued by a particular trust anchor 🔎.
Therefore, NEA Clients SHOULD be capable of establishing and holding open a TLS session with the NEA Server immediately after obtaining network access ✅. A NEA Client MAY listen for connection requests from the NEA Server and establish a new PT-TLS session when one does not already exist. Because of the potential added complexity, a NEA Client's support for accepting inbound PT-TLS connections is optional to implement. Having an existing PT-TLS session lets either party initiate an assessment without requiring the NEA Client to be listening for new connection requests 🦋. To keep the TLS session alive, the NEA Client and NEA Server SHOULD be capable of supporting the TLS heartbeat protocol [RFC6520] 💓.
3.1.2. Establish or Re-Use Existing PT-TLS Session ♻️
A single PT-TLS session can support multiple NEA assessments, and either party (the PT-TLS Initiator or the PT-TLS Responder) can start them. The party that starts a NEA assessment is known as the "assessment initiator", and the other party is known as the "assessment responder" 🎯.
If the assessment initiator already has a PT-TLS session to the assessment responder, the initiator can re-use this session. Otherwise, a new PT-TLS session needs to be established 🔁.
3.2. TCP Port Usage 🔌
In order for a PT-TLS Initiator to establish a TCP connection to a PT-TLS Responder, the initiator needs to know the TCP port number on which the responder is listening for assessment requests. The IANA has reserved TCP port number 271 for use by "pt-tls" 🍒.
3.3. Preventing MITM Attacks with Channel Bindings 🕵️♀️
Okay so, there's a sneaky attack called the Man-in-the-Middle (MITM) attack, and it can be pulled off against NEA systems, as described in "The Network Endpoint Assessment (NEA) Asokan Attack Analysis" [RFC6813] 😭. The attacker sits in the middle and forwards PA-TNC messages from a healthy machine through an unhealthy one, so the unhealthy machine can sneak onto the network 💀. Honestly, though, there are easier ways to attack NEA systems, like having the unhealthy machine just lie about its configuration, so this attack is usually only tried on machines with an External Measurement Agent (EMA) 🙄. The EMA is a separate entity that's hard to compromise, and it measures and attests to the configuration of the endpoint ✨.
To protect against NEA Asokan attacks, the Posture Broker Client on an EMA-equipped endpoint should pass the tls-unique channel binding [RFC5929] for PT-TLS's underlying TLS session to the EMA 🫶. That value can then be included in the EMA's attestation, and the Posture Validator that talks to the EMA can check that the value matches the tls-unique channel binding for its end of the connection 💅. If the values match, then the posture sent by the EMA and NEA Client comes from the same endpoint as the client side of the TLS connection (since the endpoint knows the tls-unique value), so nobody in the middle is forwarding posture 🎀. If they differ, the Asokan attack has been detected 🚨. The Posture Validator MUST fail its verification of the endpoint if the Asokan attack has been detected 🚫.
3.4. PT-TLS Message Flow 🌊
This section talks about the general flow of messages between the NEA Client's Posture Transport Client and the NEA Server's Posture Transport Server, so they can do NEA assessments using the PT-TLS protocol 🧚.
3.4.1. Assessment Triggers 🔔
Okay so first, the NEA Client or NEA Server decides that an assessment is needed 🤔. What makes that decision happen is outside the scope of this specification, but some examples include:
- NEA Server becoming aware of suspicious behavior on an endpoint
- NEA Server receiving new policies requiring immediate action
- NEA Client noticing a change in local security posture
- NEA Client wishing to access a protected network or resource
Because either the NEA Client or the NEA Server can trigger the TLS session setup and start the assessment, this document uses the terms "assessment initiator" and "assessment responder" 🦋. This naming is lowkey genius because it lets either NEA component fill either of the PT-TLS roles 👑.
3.4.2. PT-TLS Message Exchange Phases 🎬
The PT-TLS message exchange happens in three distinct phases 💖:
- TLS Setup (including TLS handshake protocol)
- PT-TLS Negotiation
- PT-TLS Data Transport
The TLS Setup phase handles setting up the TCP connection and the TLS protections for the PT-TLS messages 🔐. It starts when a TCP connection is established between the Posture Transport Client and Posture Transport Server 🌸. The new connection tells the TLS server to start the TLS handshake protocol so the cryptographic protections for the session get set up 🍓. Once the TLS Setup phase has finished (after the TLS Finished messages), the TLS session MUST NOT be renegotiated 🙅♀️. TLS session renegotiation MAY be used before the TLS Setup phase ends and the PT-TLS Negotiation phase begins 🔄. This phase also sets up the tls-unique shared secret ✨, and that secret can later be used by the PA protocol to protect against some forms of man-in-the-middle attacks 🛡️.
The PT-TLS Negotiation phase only happens at the start of the first assessment on a TLS session 🥰. During this phase, the NEA Client and NEA Server find out each other's PT-TLS capabilities and set up a context that will apply to all future PT-TLS messages sent over the TLS session 🤝. The PT-TLS Negotiation phase MUST NOT be repeated after the session has entered the Data Transport phase 🚫. NEA assessment messages (PB-TNC batches) MUST NOT be sent by the NEA Client or NEA Server before the PT-TLS Negotiation phase is complete 😤. This makes sure the security protections for the session are properly set up and applied to the NEA assessment messages 🔒.
Finally, the Data Transport phase lets the NEA Client and NEA Server swap PT messages under the protection of the TLS session, consistent with the capabilities set up in earlier phases 💜. The messages exchanged can be a PT-TLS protected NEA assessment as described in this specification, or other vendor-defined PT-TLS exchanged messages 🎁.
3.4.2.1. TLS Setup Phase 🔐
After a new TCP connection is established between the Posture Transport Client and Posture Transport Server, a standard TLS exchange happens to negotiate a common security context for protecting later communications 🌈. As discussed in Section 3.1, either the NEA Client or the NEA Server could start the TCP connection establishment and/or the TLS handshake protocol 🧸. The most common situation is for the assessment initiator to trigger the TCP connection and TLS handshake, so an assessment can begin when no session exists yet 🙌. When the NEA Server starts the TLS Setup, the NEA Server acts as a TLS client and the NEA Client is the TLS server (accepting the inbound TLS session request) 🔁. The expected normal case is for the NEA Client to start this phase, so the NEA Server acts as the TLS server, and the security bootstrapping of the TLS session uses the NEA Server's certificate 📜. Having the NEA Client start the TLS session means the NEA Client doesn't also need to have a certificate 🥳.
During the TLS Setup phase of PT-TLS, the PT-TLS Initiator contacts the listening port of the PT-TLS Responder and does a TLS handshake 🤙. The PT-TLS Responder MUST have a trustworthy X.509 certificate, which it uses to authenticate to the PT-TLS Initiator and to bootstrap the security protections of the TLS session 🏅. The PT-TLS Initiator MAY also use an X.509 certificate to authenticate to the PT-TLS Responder, which gives you bidirectional authentication of the PT-TLS session 🤩. The NEA Client MUST provide certificate validation according to the rules in RFC 5280 when it evaluates the server certificate 🧐. The NEA Client MAY perform certificate revocation checking on the NEA Server's certificate 🔍. This specification lets the NEA Client implementation decide which certificate revocation technique to implement 🤷♀️. If revocation information isn't provided in a TLS handshake extension, then clients doing certificate validation will need some network access (e.g., HTTP) to be allowed during the assessment 🌐. NEA Client network access to other non-essential services might get restricted during assessments in some situations 🚧. If the client can't access the status information, its policy may stop it from completing the TLS handshake 😬.
Also, the NEA Client MUST follow the recommendations in RFC 6125 [RFC6125] when it validates the NEA Server domain name against the contents of the server certificate, and it has to keep these restrictions in mind 📋:
- Any SRV-IDs and URI-IDs in the certificate are ignored.
- Use of CN-IDs in certificates is NOT RECOMMENDED.
- Wildcards MUST NOT appear in the DNS-ID or CN-ID of a certificate identifying a PT-TLS server.
Details for the reverse direction are given in Section 3.1 🔄.
Deploying and distributing certificates to a potentially large number of NEA Clients is a real headache 😩, so this specification lets the NEA Client be authenticated during the PT-TLS Negotiation phase using other, more cost-effective methods, as described in Section 3.8.1 💸. When the initial TLS Setup phase completes successfully, the NEA Client and NEA Server have a protected session for exchanging messages 🎉. That lets the protocol move on to the PT-TLS Negotiation phase ➡️.
3.4.2.2. PT-TLS Negotiation Phase 🤓
Once a TLS session has been set up between a Posture Transport Client and Posture Transport Server, the PT-TLS Initiator sends a Version Request message that lists its supported PT-TLS protocol version range 📨. Next, the PT-TLS Responder sends a Version Response message, which picks a protocol version from the range that was offered 🎯. The PT-TLS Responder SHOULD select the preferred version offered if it's supported 💯; otherwise, the highest version the responder can support from the received Version Request message will be used 🪜. If the PT-TLS Responder can't or won't support any of the versions in the Version Request message, the responder SHOULD send a Version Not Supported error message 🙅♀️.
If no client-side authentication happened during the TLS Setup phase, the Posture Transport Server can authenticate the client using PT-TLS client authentication messages, as described in Section 3.8 🪪. The NEA Server starts the client authentication and says when it's complete 🏁.
When the NEA Client receives the Simple Authentication and Security Layer (SASL) [RFC4422] Mechanisms list, it replies with a SASL Mechanism Selection TLV that says which authentication method to use 🗝️. After picking a suitable SASL mechanism, the NEA Client and Server swap SASL-mechanism-specific messages to authenticate the NEA Client 🔑. When client authentication finishes successfully and no more authentications are needed (which the NEA Server signals by sending an empty SASL Mechanisms list), the PT-TLS session moves into the Data Transport phase and stays there for the rest of the session 🥂. Note that the NEA Server could choose not to authenticate the client (signalled by only sending an empty SASL Mechanisms list), or to keep doing a posture assessment even if the authentication didn't complete successfully 🫠.
✨💖 Mm, that's the handshake and negotiation dance all wrapped up 💖✨
3.4.2.3. PT-TLS Data Transport Phase ✨
okay so once a PT-TLS session is ready to carry NEA assessments, PT-TLS lets either side send the first PB-TNC batch 💖 The PB-TNC standard decides whether the Posture Broker Client or the Posture Broker Server kicks things off. The assessment initiator wraps the PB-TNC batch in a PT-TLS message, gives that message a message identifier, and then sends it over the session. The assessment responder checks the PT-TLS message and hands the wrapped PB-TNC batch up to its upstream component (Posture Broker Client or Server) 🎀
Most PT-TLS messages carry PB-TNC batches that hold PA-TNC requests for posture info, or responses with the posture info that was asked for 🔍 The Posture Transport Client and Posture Transport Server can also message each other directly, like sending a PT-TLS Error message when something goes wrong while processing a message 🙈 During an assessment, they just wrap up and pass along the PB-TNC batches and have zero clue what state the assessment is in, lowkey iconic 💅
PT-TLS lets either party send a PT-TLS message at any time, which matches the full-duplex vibe of the TLS session underneath 🦋 For example, an assessment initiator might send a bunch of PT-TLS messages before any responses come back from the assessment responder. All implementations of PT-TLS MUST support full-duplex PT-TLS message exchange 🔥 Still, some higher-layer NEA protocols (e.g., PB-TNC) might not be able to fully take advantage of full-duplex exchange 🥺
3.4.3. TLS Requirements 🔐
okay, security is non-negotiable bestie. This section covers requirements for the underlying TLS transport that PT-TLS uses, so deployers always get strong security and implementations play nicely together 🫶 Whenever this spec uses TLS, the right version (or versions) will change over time based on widespread deployment and known security vulnerabilities. When this was written, TLS version 1.2 [RFC5246] was the newest, but it has a super limited deployment base and might not be easy to get your hands on for implementation. TLS version 1.0 [RFC2246] and version 1.1 [RFC4346] are the most widely deployed and give the broadest interoperability 🌈 Implementations of PT-TLS SHOULD support use of TLS 1.2.
For each TLS version supported, implementations of the PT-TLS protocol MUST at least support the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite. This cipher suite requires the server to provide a certificate that can be used during the key exchange 🍓 Implementations SHOULD NOT include support for cipher suites that don't minimally offer PT-TLS Responder (typically Posture Transport Server) authentication, such as the anonymous Diffie-Hellman cipher suites (e.g., TLS_DH_anon_WITH_AES_128_CBC_SHA) 💀 Implementations MUST support RFC 5746 [RFC5746]. Implementations MAY allow renegotiation to provide confidentiality for the client certificate. If renegotiation is allowed, implementations need to select the appropriate handshake messages as described in RFC 5929 for the tls-unique value.
3.5. PT-TLS Message Format 📦
This section describes the format and semantics of the PT-TLS message. Every message sent over a PT-TLS session MUST start with the PT-TLS header described in this section 🎀
The PT-TLS header format is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Message Type Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Value (e.g., PB-TNC Batch) . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Reserved
Saved for future use 🔮 This field MUST be set to 0 on transmission and ignored upon reception.
Message Type Vendor ID
This field says who owns the namespace associated with the message type. It does this by carrying the 24-bit Structure of Management Information (SMI) Private Enterprise Number [PEN] (Vendor ID) of the party that owns the message type namespace. Consistent with PA-TNC and PB-TNC, we depend on the PEN fitting in 24 bits, so if IANA were to register a wider PEN, then that PEN could not be used with NEA. IETF namespace PT-TLS Message Types MUST use zero (0) in this field. For more info on how NEA namespace identifiers are meant to be used, check the PA-TNC specification (RFC 5792), Sections 2.1 and 2.2 📚
The PT-TLS Message Type Vendor ID 0xffffff is reserved. Posture Transport Clients and Servers MUST NOT send PT-TLS messages in which the PT-TLS Message Type Vendor ID has this reserved value (0xffffff). If a Posture Transport Client or Posture Transport Server receives a message containing this reserved value (0xffffff) in the PT-TLS Message Type Vendor ID, the recipient SHOULD respond with an Invalid Parameter error code in a PT-TLS Error message 🚫
Message Type
This field defines the type of the PT-TLS message within the scope of the specified Message Type Vendor ID that is included in the Message Value field. The specific IETF-defined values allowed in this field when the Message Type Vendor ID is the IETF SMI Private Enterprise Number value (0) are defined in Section 3.6. Recipients of a message containing a Message Type Vendor ID and a message type that is unrecognized SHOULD respond with a Type Not Supported error code in a PT-TLS Error message 🙋
Posture Transport Clients and Posture Transport Servers MUST NOT require support for particular vendor-defined PT-TLS Message Types in order to interoperate with other PT-TLS compliant implementations (although implementations MAY permit administrators to configure them to require support for specific vendor-defined PT-TLS Message Types) 🧚
If the PT-TLS Message Type Vendor ID field has the value zero (0), then the PT-TLS Message Type field contains an IETF namespace PT-TLS Message Type, as listed in the IANA registry. IANA maintains a registry of PT-TLS Message Types. Entries in this registry are added following the IANA Specification Required policy, following the guidelines in Section 6.1. Section 3.6 of this specification defines the initial set of IETF-defined PT-TLS Message Types 🗂️
The PT-TLS Message Type 0xffffffff is reserved. Posture Transport Clients and Posture Transport Servers MUST NOT send PT-TLS messages in which the PT-TLS Message Type has this reserved value (0xffffffff). If a Posture Transport Client or Posture Transport Server receives a message in which the PT-TLS Message Type has this reserved value (0xffffffff), it SHOULD respond with an Invalid Parameter error code in a PT-TLS Error message 🚫
Message Length
This field contains the length in octets of the entire PT-TLS message (including the entire header). So this value MUST always be at least 16. Any Posture Transport Client or Posture Transport Server that receives a message with a PT-TLS Message Length field whose value is less than 16 SHOULD respond with an Invalid Parameter PT-TLS Error Code. Similarly, if a Posture Transport Client or Posture Transport Server receives a PT-TLS message for a Message Type that has a known Message Length and the Message Length indicates a different value (greater or less than the expected value), the recipient SHOULD respond with an Invalid Parameter PT-TLS Error Code 📏
Message Identifier
This field contains a value that uniquely identifies the PT-TLS message on a per message sender (Posture Transport Client or Server) basis. This value is copied into the body of the PT-TLS Error message so the recipient can figure out which message caused the error 🕵️♀️
The Message Identifier MUST be a monotonically increasing counter starting at zero, indicating the number of the messages the sender has transmitted over the TLS session. It is possible that a busy or long-lived session might exceed 2^32-1 messages sent, so the message sender MUST roll over to zero upon reaching the 2^32nd message, thus restarting the increasing counter. During a rollover, it is feasible that the message recipient could get confused if it keeps track of every previously received Message Identifier, so recipients MUST be able to handle rollover situations without generating errors 🔄
Message Value
The contents of this field vary depending on the particular Message Type Vendor ID and Message Type given in the PT-TLS header for this PT-TLS message. This field most frequently contains a PB-TNC batch. The contents of this field for each of the initial IETF namespace PT-TLS Message Types are defined in this specification 🌸
3.6. IETF Namespace PT-TLS Message Types ✨
okay bestie, this section is where the PT-TLS Message Types get their names 🦋 These are the types that carry PT-TLS messages and PB-TNC batches between the Posture Transport Client and the Posture Transport Server. main character energy for sure 💅
Here's the starter set of IETF-defined message type values. They're used with the PT-TLS Message Type Vendor ID field set to the IETF SMI PEN (0). Quick side note: the IANA looks after PEN value 0 on the IETF's behalf, and these descriptions only apply to the IETF namespace 🌸
Value (Name) Definition
---------------------------- ---------------------------------------
0 (Experimental) Reserved for experimental use. This
type will not offer interoperability
but allows for experimentation. This
message type MUST only be sent when the
NEA Client and NEA Server are in the
Data Transport phase and only on a
restricted, experimental network.
Compliant implementations MUST send an
Invalid Message error code in a PT-TLS
Error message if an Experimental
message is received.
1 (Version Request) Version negotiation request including
the range of versions supported by the
sender. This message type MUST only be
sent by the TLS session initiator as
the first PT-TLS message in the PT-TLS
Negotiation phase. Recipients MUST
send an Invalid Message error code in a
PT-TLS Error message if a Version
Request is received at another time.
2 (Version Response) PT-TLS protocol version selected by the
responder. This message type MUST only
be sent by the PT-TLS Responder as the
second message in the PT-TLS
Negotiation phase. Recipients MUST
send an Invalid Message error code in a
PT-TLS Error message if a Version
Response is received at another time.
3 (SASL Mechanisms) Sent by the NEA Server to indicate what
SASL mechanisms it is willing to use
for authentication on this session.
This message type MUST only be sent by
the NEA Server in the PT-TLS
Negotiation phase. The NEA Client MUST
send an Invalid Message error code in a
PT-TLS Error message if a SASL
Mechanisms message is received at
another time.
4 (SASL Mechanism Selection) Sent by the NEA Client to select a SASL
mechanism from the list offered by the
NEA Server. This message type MUST
only be sent by the NEA Client in the
PT-TLS Negotiation phase. The NEA
Server MUST send an Invalid Message
error code in a PT-TLS Error message if
a SASL Mechanism Selection is received
after the PT-TLS Negotiation phase.
Once a SASL mechanism has been
selected, it may not change until the
mechanism completes either successfully
or as a failure.
5 (SASL Authentication Data) Opaque octets exchanged between the NEA
Client and NEA Server's SASL mechanisms
to perform the client authentication.
This message type MUST only be sent
during the PT-TLS Negotiation phase.
Recipients MUST send an Invalid Message
error code in a PT-TLS Error message if
a SASL Authentication Data message is
received after the PT-TLS Negotiation
phase.
6 (SASL Result) Indicates the result code of the SASL
mechanism authentication as described
in Section 3.8.10. This message type
MUST only be sent by the NEA Server
when the NEA Client and NEA Server are
in the PT-TLS Negotiation phase. The
NEA Client MUST send an Invalid Message
error code in a PT-TLS Error message if
a SASL Result is received after the
PT-TLS Negotiation phase.
7 (PB-TNC Batch) Contains a PB-TNC batch. For more
information on PB-TNC batches, see
RFC 5793 (PB-TNC) Section 4. This
message type MUST only be sent when the
NEA Client and NEA Server are in the
PT-TLS Data Transport phase.
Recipients SHOULD send an Invalid
Message error code in a PT-TLS Error
message if a PB-TNC Batch is received
outside of the Data Transport phase.
8 (PT-TLS Error) PT-TLS Error message as described in
Section 3.9. This message type may be
used during any PT-TLS phase.
9-4294967294 (Unassigned) These values are for future allocation
following guidelines defined in the
IANA Considerations section (see
Section 6.1). Recipients of
unsupported messages in the IETF
namespace using a message type of 9 to
4294967294 MUST respond with a Type Not
Supported PT-TLS Error Code in a PT-TLS
Error message.
4294967295 Reserved3.7. PT-TLS Version Negotiation 🎀
okay so this part is all about how PT-TLS figures out which protocol version to use 🧚 The PT-TLS Initiator kicks things off with a version negotiation at the start of an assessment. And honestly, the rules are very strict. The Initiator MUST send a Version Request message as its first PT-TLS message, and it MUST NOT send any other PT-TLS messages on this connection until it gets a Version Response message or an Error message back 🫶
The PT-TLS Responder MUST finish the version negotiation (or cause an error) before it sends anything or accepts any more messages. After the negotiation is done, both the Posture Transport Client and the Posture Transport Server MUST only send messages that match the negotiated protocol version 💜 And for later assessments on the same session, they MUST use the negotiated version number, so they MUST NOT send any more version negotiation messages. no cap, that's a whole lot of MUSTs but they keep everyone on the same page ✨
3.7.1. Version Request Message 🌈
This is the message a PT-TLS Initiator sends as the very first PT-TLS message in a PT-TLS session. It tells the other side which versions of PT-TLS the sender supports. To keep things compatible, this message MUST always be sent using version 1 of the PT-TLS protocol. Recipients of this message MUST reply with a Version Response or a PT-TLS Error message (Version Not Supported or Invalid Message). Here's the layout 👑
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Min Vers | Max Vers | Pref Vers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Now let's go field by field 🍓
Reserved
Reserved for future use. This field MUST be set to 0 on transmission and ignored upon reception.
Min Vers
This field holds the minimum version of the PT-TLS protocol that the sender supports. This field MUST be set to 1, which means support for the first version of PT-TLS. Heads up though: future versions of this specification will probably drop this requirement, so PT-TLS Responders MUST be prepared to receive other values 🔮
Max Vers
This field holds the maximum version of the PT-TLS protocol that the sender supports. This field MUST be set to 1, which means support for the first version of PT-TLS. Same deal as Min Vers: future versions will probably remove this requirement, so PT-TLS Responders MUST be prepared to receive other values 💅
Pref Vers
This field holds the sender's preferred version of the PT-TLS protocol. Think of it as a hint telling the recipient "pls pick this one if you can" 🥺 The value of this field MUST fall within the range of Min Vers to Max Vers. This field MUST be set to 1, which means support for the first version of PT-TLS. And yep, you guessed it, future versions will probably remove this requirement, so PT-TLS Responders MUST be prepared to receive other values.
3.7.2. Version Response Message 🦋
This message gets sent back in reply to a Version Request at the start of a new assessment session. If a recipient gets a Version Request after a successful version negotiation has already happened on the session, the recipient MUST send an Invalid Message error code in a PT-TLS Error message and have TLS close the session. So rude, but it's the rule 🙈 This message MUST be sent using the syntax, semantics, and requirements of the protocol version named in this message. Here's the layout:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Reserved
Reserved for future use. This field MUST be set to 0 on transmission and ignored upon reception.
Version
This field holds the version the sender of this message picked. The version selected MUST be inside the Min Vers to Max Vers inclusive range that was sent in the Version Request message. If a PT-TLS Initiator gets a message with an invalid Version selected, the PT-TLS Initiator MUST respond with a Version Not Supported PT-TLS Error message 😭
3.8. Client Authentication Using SASL ✨
okay bestie, this section is all about how the NEA Client gets authenticated over PT-TLS 🔐 (aka proving who it is). It matters when the NEA Server needs that auth and it didn't already happen during the TLS handshake. The plan is to plug into the Simple Authentication and Security Layer (SASL) [RFC4422] framework, which gives you a bunch of standards-based auth mechanisms that can verify the NEA Client using all kinds of base tech 💅.
Client authentication could happen during the TLS handshake using TLS-defined auth techniques 🌸. Since that client auth is optional, the NEA Server's policy might still want the client authenticated by PT-TLS before the assessment happens 👀. The NEA Server may also ask for a PT-TLS auth even if the NEA Client already got authed during the handshake (like a user auth after a system-level auth happened in the handshake 🙈). Whether a SASL client auth happens at all is up to the NEA Server's policy 👑.
As discussed in Section 3.1.1, the NEA Server might start the TLS session to the NEA Client, which means the NEA Client ends up as the TLS client in the handshake 🦋. The NEA Server has to have an X.509 certificate for when it's acting as the TLS server (the normal case), so PT-TLS says the NEA Server MUST use its X.509 certificate for TLS client authentication during the TLS handshake to authenticate itself even when it is acting as the TLS client. In that case the NEA Client and NEA Server both authenticate with certificates during the handshake, so PT-TLS SASL client auth might not be needed unless the NEA Server's policy wants an extra auth of the NEA Client. Basically, the normal use of the SASL messages is when the NEA Client acted as the TLS client and didn't authenticate during the handshake 💖.
3.8.1. SASL Client Authentication Requirements 🔐
Implementations compliant with the PT-TLS specification MUST implement the PT-TLS client authentication messages described in this section. These messages can carry a whole bunch of SASL mechanism exchanges 🧩. For interop, all PT-TLS implementations compliant with this specification MUST at least support the PLAIN SASL mechanism [RFC4616]. Similarly, implementations MUST provide the EXTERNAL SASL mechanism if both parties are authenticated during the TLS establishment. To take advantage of other strong, widely deployed auth technologies like Kerberos and support for channel bindings, implementations MAY include support for GS2 (the second Generic Security Service Application Program Interface (GSS-API) bridge for SASL) [RFC5801]. GS2 includes negotiable support for channel binding for use with SASL (see Section 5 of RFC 5801).
Implementations MUST also support the case where no client authentication is required 🙌.
3.8.2. SASL in PT-TLS Overview 🗺️
Mechanism negotiation kicks off when the NEA Server sends the SASL Mechanisms TLV to the NEA Client, indicating the zero or more SASL mechanisms its policy is willing to use with the NEA Client. The NEA Client picks one from the list and sends a SASL Mechanism Selection TLV to finish the negotiation 🤝. Later challenges and responses ride along in the SASL Authentication Data TLV, which carries the auth data for the selected mechanism. The outcome comes back in a SASL Result TLV containing a status code 📬. If more auths are needed, the NEA Server could trigger the next one by sending another SASL Mechanisms TLV after the SASL Result TLV for the current mechanism 🔁.
3.8.3. SASL Authentication Flow 🌊
The SASL client auth starts when the NEA Server enters the PT-TLS Negotiation phase and its policy says the NEA Client needs to be authenticated, like if that didn't happen during the TLS handshake protocol. The NEA Server is in charge of triggering it by sending the SASL Mechanisms TLV, listing the set of SASL mechanisms it's willing to use based on its policy 📣.
The NEA Client either selects a SASL mechanism from the list the NEA Server proposed, or sends a PT-TLS Invalid Message error code saying it's unable or unwilling to perform any of the offered mechanisms 🙅♀️. If the NEA Server gets a SASL Mechanism Selection TLV with an unacceptable mechanism, the NEA Server would respond with a SASL Mechanism Error in a PT-TLS Error TLV 💀.
In situations where the NEA Server doesn't require a client authentication, the NEA Server MUST send a SASL Mechanisms TLV with no mechanisms included (only the PT-TLS header) to say the connection should transition to the PT-TLS Data Transport phase 🚪. The same move signals that a SASL authentication already performed in this session is good enough to permit the transition. So the NEA Server MUST always send a SASL Mechanisms TLV with no mechanisms as the last message in the PT-TLS Negotiation phase, and the NEA Client MUST NOT transition to the PT-TLS Data Transport phase until it receives such a message ⛔.
If the NEA Server gets a NEA assessment message before client auth wraps up, the NEA Server MUST send an Authentication Required PT-TLS Error message telling the NEA Client that an authentication exchange is required before entering the PT-TLS Data Transport phase 🚧.
3.8.4. Aborting SASL Authentication 🛑
The NEA Server may abort the auth exchange by sending the SASL Result TLV with a status code of Abort. The NEA Client may abort it by sending a PT-TLS Error message with an Error Code of SASL Mechanism Error 🙃.
3.8.5. Linkages to SASL Framework 🔗
3.8.5.1. SASL Service Name
The service name for PT-TLS is "nea-pt-tls" 🏷️.
3.8.5.2. SASL Authorization Identity
The PT-TLS protocol does not make use of a SASL authorization identity string as described in RFC 4422 🙅.
3.8.5.3. SASL Security Layer
The NEA PT-TLS protocol always runs under the protection of TLS 🛡️. SASL security layers are not used, so they MUST be negotiated off during SASL authentication 🔕.
3.8.5.4. Multiple Authentications
Only one SASL mechanism authentication may be in progress at any one time 🙋♀️. Once a SASL mechanism completes (successfully or unsuccessfully), the NEA Server MAY trigger an additional authentication by sending a SASL Mechanisms TLV 🔄.
3.8.6. SASL Channel Bindings 🔒
SASL channel bindings tie the SASL authentication to the outer TLS tunnel, so the authenticating endpoints are guaranteed to be the same as the TLS endpoints 🧷. For SASL mechanisms that support channel bindings, the tls-unique value defined in RFC 5929 is carried by the SASL mechanism. For most mechanisms, this means including the tls-unique value, with the appropriate prefix defined in RFC 5929, in the application data portion of the SASL Mechanism channel-binding data. If the validation of the channel binding fails, then the connection MUST be aborted 🚨.
3.8.7. SASL Mechanisms 📜
This TLV is sent by the NEA Server to indicate the list of SASL mechanisms that it is willing and able to use to authenticate the NEA Client 📋. Each mechanism name consists of a length followed by a name. The total length of the list is determined by the TLV Length field.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd| Mech Len| Mechanism Name (1-20 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd| Mech Len| Mechanism Name (1-20 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . . . . . . . . . |Rsvd (Reserved)
Reserved for future use. This field MUST be set to 0 on transmission and ignored upon reception 🧹.
Mech Len (Mechanism Name Length)
The length of the Mechanism Name field in octets 📏.
Mechanism Name
SASL mechanism name adhering to the rules defined in RFC 4422 with no padding 🏷️.
3.8.8. SASL Mechanism Selection 🎯
This TLV is sent by the NEA Client in order to select a SASL mechanism for use on this session 👆.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd| Mech Len| Mechanism Name (1-20 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Initial Mechanism Response |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Rsvd (Reserved)
Reserved for future use. This field MUST be set to 0 on transmission and ignored upon reception 🧹.
Mech Len (Mechanism Name Length)
The length of the Mechanism Name field in octets 📏.
Mechanism Name
SASL mechanism name adhering to the rules defined in RFC 4422 🏷️.
Optional Initial Mechanism Response
Initial set of authentication information required from the NEA Client to kick-start the authentication. This data is optional, and if not provided, it would be solicited by the NEA Server in the first SASL Authentication Data TLV request 🚀.
3.8.9. SASL Authentication Data 📦
This TLV carries an opaque (to PT-TLS) blob of octets being exchanged between the NEA Client and the NEA Server 🎁. It facilitates their communications without interpreting any of the bytes, so PT-TLS just passes the goods along 🙈. The SASL Authentication Data TLV MUST NOT be sent until a SASL mechanism has been established for a session. The SASL Authentication Data TLV associated with the current authentication mechanism MUST NOT be sent after a SASL Result is sent with a Result Code of Success. Additional SASL Authentication Data TLVs would be sent if the PT-TLS Initiator and Responder want a subsequent SASL authentication to occur, but only after another SASL mechanism selection exchange occurs 🔁.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SASL Mechanism Data (Variable Length) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+SASL Mechanism Data
Opaque, variable-length set of bytes exchanged between the PT-TLS Initiator's SASL mechanism and its peer PT-TLS Responder's SASL mechanism. These bytes MUST NOT be interpreted by the PT-TLS layer 🙊.
3.8.10. SASL Result ✨
okay so this TLV is sent by the NEA Server at the end of the SASL exchange to spill the tea on how the authentication went 💅. When the NEA Client gets a SASL Result TLV that says Abort, it MUST terminate the current authentication conversation 🛑. The recipient may retry the authentication if it failed 🔁. And the NEA Server may ask for more SASL authentications after a mechanism finishes, by sending another SASL Mechanisms TLV with whatever mechanisms its policy calls for 🧚.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Optional Result Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . . . . . . . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Result Code 🎯
This field tells you the result of the SASL authentication exchange 👀.
Value (Name) Definition
--------------------- -------------------------------------------
0 (Success) SASL authentication was successful, and
identity was confirmed.
1 (Failure) SASL authentication failed. This might be
caused by the client providing an invalid
user identity and/or credential pair. Note
that this is not the same as a mechanism's
failure to process the authentication as
reported by the Mechanism Failure code.
2 (Abort) SASL authentication exchange was aborted by
the sender.
3 (Mechanism Failure) SASL "mechanism failure" during the
processing of the client's authentication
(e.g., not related to the user's input).
For example, this could occur if the
mechanism is unable to allocate memory
(e.g., malloc) that is needed to process a
received SASL mechanism message.Optional Result Data 🎁
This field holds a variable-length set of extra data for a successful result 🌈. It MUST be zero length unless the NEA Server is returning a Result Code of Success and has more data to send back. If you want the details on extra data with success in SASL, check out RFC 4422 📚.
3.9. Error Message 🚨
this section covers the format and contents of the PT-TLS Error message, which the NEA Client or NEA Server sends when it spots a PT-TLS-level protocol error 🙈. Each error message has an error code saying what went wrong, followed by a copy of the message that caused it.
When you get a PT-TLS error, you MUST NOT reply with a PT-TLS error, because that could start an infinite loop of error messages being sent back and forth 🔁💀. Instead, you MAY log the error, change your behavior to avoid future errors, ignore it, end the assessment, or do something else that makes sense (as long as it still follows the requirements of this specification) 🧚.
The Message Value portion of a PT-TLS Error message has the following info:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Error Code Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Copy of Original Message (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . . . . . |Reserved 🫧
This is reserved for future use 🔮. It MUST be set to 0 when sent and ignored when received.
Error Code Vendor ID 🏷️
This field has the IANA-assigned SMI Private Enterprise Number for the vendor whose Error Code namespace is used in this message 🏢. For IETF namespace Error Code values, this field MUST be set to zero (0). For other vendor-defined Error Code namespaces, this field MUST be set to that vendor's SMI Private Enterprise Number 💜.
Error Code 🧨
This field has the error code 🙋. The error code only means something within the scope of the Error Code Vendor ID in this message. Posture Transport Clients and Posture Transport Servers MUST NOT require support for particular vendor-specific PT-TLS Error Codes just to interoperate with other PT-TLS-compliant implementations (though implementations MAY let admins configure them to require support for specific PT-TLS Error Codes) 🛠️.
When the Error Code Vendor ID is set to the IETF Private Enterprise Number, here are the initial IETF-defined numeric error codes 📋:
Value (Name) Definition
------------------------- ---------------------------------------
0 (Reserved) Reserved value indicates that the
PT-TLS Error message SHOULD be ignored
by all recipients. This MAY be used
for debugging purposes to allow a
sender to see a copy of the message
that was received.
1 (Malformed Message) PT-TLS message unrecognized or
unsupported. This error code SHOULD be
sent when the basic message content
sanity test fails. The sender of this
error code MUST consider it a fatal
error and abort the assessment.
2 (Version Not Supported) This error SHOULD be sent when a PT-TLS
Responder receives a PT-TLS Version
Request message containing a range of
version numbers that doesn't include
any version numbers that the recipient
is willing and able to support on the
session. All PT-TLS messages carrying
the Version Not Supported error code
MUST use a version number of 1. All
parties that receive or send PT-TLS
messages MUST be able to properly
process an error message that meets
this description, even if they cannot
process any other aspect of PT-TLS
version 1. The sender and receiver of
this error code MUST consider it a
fatal error and close the TLS session
after sending or receiving this PT-TLS
message.
3 (Type Not Supported) PT-TLS Message Type unknown or not
supported. When a recipient receives a
PT-TLS Message Type that it does not
support, it MUST send back this error,
ignore the message, and proceed. For
example, this could occur if the sender
used a Vendor ID for the Message Type
that is not supported by the recipient.
This error message does not indicate
that a fatal error has occurred, so the
assessment is allowed to continue.
4 (Invalid Message) PT-TLS message received was invalid
based on the protocol state. For
example, this error would be sent if a
recipient receives a message associated
with the PT-TLS Negotiation Phase (such
as Version messages) after the protocol
has reached the PT-TLS Data Transport
Phase. The sender and receiver of this
error code MUST consider it a fatal
error and close the TLS session after
sending or receiving this PT-TLS
message.
5 (SASL Mechanism Error) A fatal error occurred while trying to
perform the client authentication. For
example, the NEA Client is unable to
support any of the offered SASL
mechanisms. The sender and receiver of
this error code MUST consider it a
fatal error and close the TLS session
after sending or receiving this PT-TLS
message.
6 (Invalid Parameter) The PT-TLS Error message sender has
received a message with an invalid or
unsupported value in the PT-TLS header.
This could occur if the NEA Client
receives a PT-TLS message from the NEA
Server with a Message Length of zero
(see Section 3.5 for details). The
sender and receiver of this error code
MUST consider it a fatal error and
close the TLS session after sending or
receiving this PT-TLS message.Copy of Original Message 📨
This variable-length value MUST contain a copy (up to 1024 bytes) of the original PT-TLS message that caused the error 🕵️♀️. If the original message is longer than 1024 bytes, only the first 1024 bytes get included. It's there so the error recipient can figure out which message caused the problem, and in particular it can use the Message Identifier field from the copy to find the culprit 🔍.
4. Security Considerations 🔐
this section talks about the major threats each binding of the PT protocol might face, and the countermeasures the PT-TLS protocol gives you to fight them 🛡️😤. It's serious business, bestie, so pay attention 👑.
4.1. Trust Relationships ✨
Okay bestie, before we get into what could go wrong, we need to know who trusts who 🫶. In order to figure out where security countermeasures are needed, the NEA architecture sets up some trust relationships between the processing elements of the PT-TLS protocol. If an implementation or deployment doesn't have these relationships, it would need extra countermeasures to keep PT-TLS working properly and securely, because PT-TLS depends on these relationships being trustworthy 💅. The next subsections go through the trust properties for each part of the NEA reference model that's directly involved in processing PT-TLS.
4.1.1. Posture Transport Client 🎀
The Posture Transport Client is trusted by the Posture Broker Client 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 Client for transmission on the network
- Transmit on the network any PB-TNC batches passed down from the Posture Broker Client
- Deliver properly security protected messages received from the network that are destined for the Posture Broker Client
- Provide configured security protections (e.g., 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 only to the PB-TNC layer within the NEA Client
- Verify the security protections placed upon messages received from the network to ensure that the messages are authentic and protected from attacks on the network
- Provide a secure, reliable, "in-order delivery", full-duplex transport for the Posture Broker Client's messages
The Posture Transport Client is trusted by the Posture Transport Server to:
- Not send malicious traffic intending to harm (e.g., denial of service) the Posture Transport Server
- Not send malformed messages (e.g., messages lacking a PT-TLS header)
- Not send invalid or incorrect responses to messages (e.g., errors when no error is warranted)
- Not ignore or drop messages when such an action would cause issues for the protocol processing (e.g., dropping PT-TLS SASL Authentication Data messages)
- Verify the security protections placed upon messages received from the network to ensure that the messages are authentic and protected from attacks on the network
4.1.2. Posture Transport Server 🧚
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
- Deliver properly security protected messages received from the network that are destined for the Posture Broker Server
- 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 only to the PB-TNC layer within the NEA Server
- Verify the security protections placed upon messages received from the network to ensure that the messages are authentic and protected from attacks on the network
- Provide a secure, reliable, "in-order delivery", full-duplex transport for the Posture Broker Server's messages
The Posture Transport Server is trusted by the Posture Transport Client to:
- Not send malicious traffic intending to harm (e.g., denial of service) the Posture Transport Client
- Not send malformed messages (e.g., messages lacking a PT-TLS header)
- Not send invalid or incorrect responses to messages (e.g., errors when no error is warranted)
- Not ignore or drop messages when such an action would cause issues for the protocol processing (e.g., dropping PT-TLS SASL Result messages)
- Verify the security protections placed upon messages received from the network to ensure that the messages are authentic and protected from attacks on the network
4.2. Security Threats and Countermeasures 🛡️
Beyond the trust relationships assumed in Section 4.1, PT-TLS has to deal with a bunch of potential security attacks that could call for countermeasures 😤.
Generally speaking, PT-TLS is responsible for giving strong security protections to all of the NEA protocols. That means any threat to its ability to protect NEA protocol messages could do serious damage to deployments 😭. 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 Theft 🕵️♀️
When PT-TLS messages travel over unprotected network links, or span local software stacks that aren't trusted, the contents can be stolen by someone in the middle 💀. That theft could mean information gets recorded for later use or analysis by the adversary. Messages that eavesdroppers see could reveal weaknesses in the endpoint's security or system fingerprinting info, which would make it way easier for an attacker to launch attacks that are more likely to work against the endpoint 👀. The eavesdropper might also learn things about the endpoint or network policies that, on their own or together, count as sensitive information. For example, if PT-TLS doesn't provide confidentiality protection, an adversary could look at the PA-TNC attributes in the PT-TLS message and figure out that the endpoint is missing patches or that certain sub-networks have more lenient policies 🙈.
To guard against NEA assessment message theft, PT-TLS provides strong cryptographic authentication, integrity, and confidentiality protection 🔐. Deployers are strongly encouraged to use "best practice of the day" TLS ciphers, so the information stays safe even as technology advances and cipher weaknesses are discovered 🌸. Using bidirectional authentication on the assessment transport session makes sure that only properly authenticated and authorized parties can be involved in an assessment dialog 🫶. PT-TLS also provides strong cryptography for all of the PB-TNC and PA-TNC protocol messages traveling over the network. That keeps the message contents hidden from theft, even if the attacker can see the encrypted PT-TLS session 🦋.
4.2.2. Message Fabrication 🧁
Attackers on the network, or sitting somewhere inside the NEA system, could slip in fabricated PT-TLS messages to trick someone or cause a denial of service against parts of an assessment 😈. For example, an adversary could try to insert fake PT-TLS Error Codes into the message exchange to mess up communications.
PT-TLS gives strong security protections to the whole message exchange over the network, and those protections keep an intermediary from inserting fake messages into the assessment ✨. TLS's use of hashing algorithms gives strong integrity protections, which means any change to the content of the message stream can be detected 🔍. On top of that, adversaries can't see the PT-TLS protocol exchanges because they're encrypted by the TLS ciphers. So they'd have a hard time working out where to insert a falsified message, since the attacker can't tell where the message boundaries are 🙃. And even if a message insertion did succeed, the recipient would still detect it, because the TLS cipher suite's integrity check would fail 💅.
4.2.3. Message Modification 🪄
This attack lets an active attacker who can intercept a message change a PT-TLS message or a transported PA-TNC attribute to a value of their choosing, which makes 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 modify the attribute exchange.
PT-TLS uses TLS to provide strong authentication and integrity protections as a countermeasure to this threat 🫶. Bidirectional authentication stops the attacker from acting as an active man-in-the-middle on the protocol, which is what they'd need to modify the message exchange 🙅♀️. The strong integrity protection that TLS offers (e.g., hashing) lets PT-TLS message recipients catch alterations made by other kinds of network-based adversaries 🔥.
4.2.4. Denial of Service 🚫
A bunch of denial-of-service attacks are possible against PT-TLS if the message exchanges are left unprotected while traveling over the network 😤. The Posture Transport Client and Posture Transport Server are trusted not to take part in a denial of service against the assessment session, which means the threats have to come from the network 🌐.
PT-TLS provides bidirectional authentication so that a man-in-the-middle on the network can't quietly become an active proxy for PT-TLS messages 🦋. PT-TLS runs after the TLS handshake, and so after cipher establishment and use, which means all of the PT-TLS messages are protected from undetected modification that could create a denial-of-service situation 🔐. Even so, an adversary can still alter the message flows, and that would make each message get rejected by the recipient, because it fails the integrity checking 😭.
PT-TLS works as an application protocol on top of TLS and therefore on top of TCP/IP protocols, so it can be hit by denial-of-service attacks aimed at TLS, TCP, and IP 💀.
4.2.5. NEA Asokan Attacks 🦹♀️
As described in Section 3.3 and in [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. Section 3.3 and [RFC6813] give a detailed description of this attack, along with the countermeasures that can be used against it 📚.
Lying endpoint attacks are way easier to pull off than Asokan attacks. The only known 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 🤓. However, PT-TLS implementers may not know whether an EMA will be used with their implementation. So PT-TLS implementers SHOULD support the Asokan attack countermeasures described in Section 3.3 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 🫶.
The Asokan attack can also apply to authentication mechanisms carried within TLS. SASL mechanisms that provide channel bindings use the tls-unique channel-binding data as defined in Section 3.3 to protect against the attack 🌈.
4.2.6. Trust Anchors ✨
okay so PT-TLS has to decide whether to trust whoever signed the certificates it gets during TLS authentication, and it makes that call by checking a set of trust anchor certificates 🔐. these need to be integrity protected from unauthorized modification, no cap, that's essential 💀. lots of software (browsers, operating systems, security protocols) comes with its own trust anchor set, but PT-TLS SHOULD use its own PT-TLS-specific set so that only certain Certificate Authorities are allowed to issue certificates for NEA. that's giving least-privilege main character energy 👑🎀
5. Privacy Considerations 🫶
bestie, PT-TLS basically exists to be the secure transport for PB-TNC and other higher-layer protocols 🚚. it doesn't directly touch personally identifiable information (PII) unless client authentication is turned on 🙈. when that happens, the NEA Client gets asked to use SASL, which may reveal a local identifier (like a username) and an authenticator (like a password) to prove that identity. since that stuff is potentially privacy-sensitive, the NEA Client MUST offer a mechanism to restrict which NEA Servers get to receive it 🔒. the NEA Client SHOULD also show the person being identified that a request for their identity has been made, so they can opt out and stay anonymous, unless there's no user interface available 🦋.
PT-TLS gives higher-layer NEA protocols cryptographic peer authentication, message integrity, and data confidentiality, which is very iconic because those protocols may exchange data that includes PII ✨. these security services can protect any PII involved in an assessment from passive and active attackers on the network 💜. endpoints sending potentially privacy-sensitive information SHOULD make sure the PT-TLS security protections (TLS cipher suites) negotiated for an assessment of the endpoint are strong enough to prevent interception and off-line attacks on any long-term privacy-sensitive information, unless other network protections are already in place 🌸💅
6. IANA Considerations 📚
okay so this specification creates two new IANA registries and assigns a TCP port number 🍓. IANA has permanently reserved the early allocated TCP port number 271 for PT-TLS 🧚.
this section defines the contents of two new IANA registries, PT-TLS Message Types and PT-TLS Error Codes, and explains how they work 🌈.
both registries support IETF-defined values and vendor-defined values. we'll use PT-TLS Message Type as the example, but the other registry works the exact same way 💖.
whenever a PT-TLS Message Type shows up on the network, it always comes with an SMI Private Enterprise Number (PEN), also known as a vendor ID 🎀. if the vendor ID is zero, the PT-TLS Message Type is an IETF namespace value listed in the IANA registry for PT-TLS Message Types, and its meaning is defined in the specification listed for it in that registry 👑. if the vendor ID is not zero, the meaning is defined by the vendor identified by that vendor ID (as listed in the IANA registry for SMI PENs) ✨. the identified vendor is encouraged, but not required, to register with IANA some or all of the PT-TLS Message Types used with their vendor ID, and to publish a specification for each one 🫶.
6.1. Designated Expert Guidelines 🧑⚖️
for each of the IANA registries defined here, new values get added by following the IANA Specification Required policy [RFC5226] 📝.
this section gives guidance to designated experts so they can make decisions with a philosophy that fits these registries 🔮.
the registries here have plenty of values. in most cases the IETF has approximately 2^32 values to define, and each vendor has the same number for its own use 🌌. because there are so many, designated experts shouldn't be terribly worried about running out 🙅♀️.
instead, they should focus on these requirements. all values in these IANA registries are required to be documented in a specification that is permanently and publicly available. IETF namespace values must also be useful, not harmful, to the Internet, and defined in a way that's clear and likely to ensure interoperability 💯.
designated experts should encourage vendors to avoid defining similar but incompatible values, and to agree on a single IETF-reviewed approach and value instead. still, it's beneficial to document existing practice 📖.
there are a few ways to make sure a specification is permanently and publicly available. it can be published as an RFC 🏆. or it can be published another way that makes it freely available to anyone. in that second case, though, the vendor needs to supply a copy to IANA and authorize IANA to archive it and make it freely available to all if the document ever stops being freely available through other channels 🗂️.
the next two sections guide IANA in creating and managing the new registries defined by this specification 💅.
6.2. Registry for PT-TLS Message Types 📮
the name of this registry is "PT-TLS Message Types". each entry should include a human-readable name, an SMI Private Enterprise Number, a decimal integer value between 0 and 4294967294, and a reference to the specification where the contents of that message type are defined. this specification must define the meaning of the PT-TLS Message Type, plus the format and semantics of the PT-TLS Message Value field, which includes the designated Private Enterprise Number in the PT-TLS Message Type Vendor ID field and the designated numeric value in the PT-TLS Message Type field 🧠.
these entries are defined in this document. more entries get added by following the IANA Specification Required policy, consistent with the guidelines in Section 6.1 🥰.
PEN Value Name Reference
--- -------- ------------------------ ---------
0 0 Experimental RFC 6876
0 1 Version Request RFC 6876
0 2 Version Response RFC 6876
0 3 SASL Mechanisms RFC 6876
0 4 SASL Mechanism Selection RFC 6876
0 5 SASL Authentication Data RFC 6876
0 6 SASL Result RFC 6876
0 7 PB-TNC Batch RFC 6876
0 8 PT-TLS Error RFC 6876
0 9-4294967294 Unassigned
0 4294967295 Reserved RFC 6876the IETF (PEN 0) PT-TLS Message Type values from 9 through 4294967294, inclusive, are allocated for future assignment by IANA 🔜.
6.3. Registry for PT-TLS Error Codes 🚨
the name of this registry is "PT-TLS Error Codes". each entry should include a human-readable name, an SMI Private Enterprise Number, a decimal integer value between 0 and 4294967295, and a reference to the specification where that error code is defined. this specification must define the meaning of the error code, a PT-TLS Message Type of PT-TLS Error, the designated Private Enterprise Number in the PT-TLS Error Code Vendor ID field, and the designated numeric value in the PT-TLS Error Code field 🎯.
these entries are defined in this document. more entries get added following the IANA Specification Required policy, consistent with the guidelines in Section 6.1 💫.
PEN Value Name Reference
--- ------------ --------------------- ---------
0 0 Reserved RFC 6876
0 1 Malformed Message RFC 6876
0 2 Version Not Supported RFC 6876
0 3 Type Not Supported RFC 6876
0 4 Invalid Message RFC 6876
0 5 SASL Mechanism Error RFC 6876
0 6 Invalid Parameter RFC 6876
0 7-4294967295 Unassignedthe IETF (PEN 0) PT-TLS Error Codes from 7 through 4294967295, inclusive, are allocated for future assignment by IANA 🌟.
7. Acknowledgments 🙌
big thanks to the Trusted Computing Group for contributing the initial text this document was based on [IFT-TLS] 💜.
the authors would also like to shout out these people, who contributed to or gave substantial input on this document or its predecessors: Syam Appala, Stuart Bailey, Lauren Giroux, Steve Hanna, Josh Howlett, Scott Kelly, Carolin Latze, Sung Lee, Lisa Lorenzin, Alexey Melnikov, Ravi Sahita, Subbu Srinivasan, Susan Thomson, and Mark Townsend 🦋✨.
8. References 📑
8.1. Normative References 📌
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
- [RFC4616] Zeilenga, K., Ed., "The PLAIN Simple Authentication and Security Layer (SASL) Mechanism", RFC 4616, August 2006.
- [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.
- [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
- [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, February 2010.
- [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.
- [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
- [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, February 2012.
8.2. Informative References 📚
these are the bonus reads, bestie. not required to build the thing, but super useful if you want the full story 🤓✨
[IFT-TLS] Trusted Computing Group, "TNC IF-T: Binding to TLS",
<http://www.trustedcomputinggroup.org/>, May 2009.
[PEN] IANA Private Enterprise Numbers (PEN) registry,
<http://www.iana.org/assignments/enterprise-numbers>.
[PT-EAP] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture
Transport (PT) Protocol For EAP Tunnel Methods", Work in
Progress, January 2013.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, June 2008.
[RFC5801] Josefsson, S. and N. Williams, "Using Generic Security
Service Application Program Interface (GSS-API)
Mechanisms in Simple Authentication and Security Layer
(SASL): The GS2 Mechanism Family", RFC 5801, July 2010.
[RFC6813] Salowey, J. and S. Hanna, "The Network Endpoint
Assessment (NEA) Asokan Attack Analysis", RFC 6813,
December 2012.Authors' Addresses ✨
meet the squad who wrote this bad boy 💖🫶
Paul Sangster
Symantec Corporation
6825 Citrine Dr.
Carlsbad, CA 92009
EMail: paul_sangster@symantec.com
Nancy Cam-Winget
Cisco Systems
80 West Tasman Drive
San Jose, CA 95134
US
EMail: ncamwing@cisco.com
Joseph Salowey
Cisco Systems
2901 Third Avenue
Seattle, WA 98121
US
EMail: jsalowey@cisco.comand that's a wrap on RFC 6876, periodt! 🌈👑💅
📦 where this page comes from
- ietf: rfc6876 2013-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms