RFC 5793
PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)
Part 1 of 15 💖
Title Block ✨
- Series: Internet Engineering Task Force (IETF), Request for Comments 5793, so this is RFC 5793 💅
- Category: Standards Track 🔥
- ISSN: 2070-1721
- Date: March 2010
- Authors: R. Sahita (Intel), S. Hanna (Juniper), R. Hurst (Microsoft), and K. Narayan (Cisco Systems) 👑
- Obsoletes / Updates: the header doesn't list either one, so this document doesn't name anything it obsoletes or updates 🙈
PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC) 🦋
Abstract 🌸
Okay so this doc specifies PB-TNC, a Posture Broker protocol that is identical to the Trusted Computing Group's IF-TNCCS 2.0 protocol. Then it checks PB-TNC against the requirements in the NEA Requirements specification. Iconic, honestly 💜
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 went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 5741 🧚
Info about the current status of this document, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc5793 🍓
Copyright Notice 🌈
Copyright (c) 2010 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 of this document. Please actually read these, bestie, 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.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of that material may not have granted the IETF Trust the right to allow modifications outside the IETF Standards Process. Without an adequate license from those person(s), this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Not a vibe to ignore 💀
Table of Contents 📖
1. Introduction ....................................................4
1.1. Prerequisites ..............................................4
1.2. Message Diagram Conventions ................................4
1.3. Terminology ................................................4
1.4. Conventions Used in This Document ..........................4
2. PB-TNC Design Considerations ....................................5
2.1. Message Addressing .........................................5
2.2. Vendor IDs .................................................7
2.3. Efficiency .................................................7
3. PB-TNC Protocol Description .....................................7
3.1. Protocol Overview ..........................................7
3.2. PB-TNC State Machine .......................................8
3.3. Layering on PT ............................................11
3.4. Example of PB-TNC Encapsulation ...........................12
4. PB-TNC Protocol Specification ..................................13
4.1. PB-TNC Header .............................................13
4.2. PB-TNC Message ............................................16
4.3. IETF Standard PB-TNC Message Types ........................19
4.4. PB-Experimental ...........................................19
4.5. PB-PA .....................................................20
4.6. PB-Assessment-Result ......................................25
4.7. PB-Access-Recommendation ..................................26
4.8. PB-Remediation-Parameters .................................28
4.9. PB-Error ..................................................32
4.10. PB-Language-Preference ...................................37
4.11. PB-Reason-String .........................................38
5. Security Considerations ........................................41
5.1. Threat Model ..............................................41
5.2. Countermeasures ...........................................42
6. IANA Considerations ............................................43
6.1. Designated Expert Guidelines ..............................44
6.2. Registry for PB-TNC Message Types .........................45
6.3. Registry for PA Subtypes ..................................45
6.4. Registry for PB-TNC Remediation Parameters Types ..........46
6.5. Registry for PB-TNC Error Codes ...........................46
7. Acknowledgments ................................................47
8. References .....................................................47
8.1. Normative References ......................................47
8.2. Informative References ....................................48
Appendix A. Use Cases .............................................49
A.1. Initial Client-Triggered Assessment .......................49
A.2. Server-Initiated Assessment with Remediation ..............54
A.3. Client-Triggered Reassessment .............................63
Appendix B. Evaluation against NEA Requirements ...................70
B.1. Evaluation against Requirement C-1 ........................70
B.2. Evaluation against Requirement C-2 ........................70
B.3. Evaluation against Requirement C-3 ........................70
B.4. Evaluation against Requirement C-4 ........................71
B.5. Evaluation against Requirement C-5 ........................71
B.6. Evaluation against Requirement C-6 ........................71
B.7. Evaluation against Requirement C-7 ........................72
B.8. Evaluation against Requirement C-8 ........................72
B.9. Evaluation against Requirement C-9 ........................72
B.10. Evaluation against Requirement C-10 ......................73
B.11. Evaluation against Requirement C-11 ......................73
B.12. Evaluation against Requirement PB-1 ......................74
B.13. Evaluation against Requirement PB-2 ......................74
B.14. Evaluation against Requirement PB-3 ......................74
B.15. Evaluation against Requirement PB-4 ......................75
B.16. Evaluation against Requirement PB-5 ......................75
B.17. Evaluation against Requirement PB-6 ......................761. Introduction ✨
This doc specifies PB-TNC, a Posture Broker (PB) protocol identical to the Trusted Computing Group's IF-TNCCS 2.0 protocol [7]. Then it evaluates PB-TNC against the requirements defined in the Network Endpoint Assessment (NEA) Requirements specification [8]. Main character energy 👑
1.1. Prerequisites 🎀
This document does not define an architecture or reference model. Instead, it defines a protocol that works inside the reference model described in the NEA Requirements specification [8]. You're assumed to be thoroughly familiar with that document, no pressure 😭 No familiarity with TCG specifications is assumed.
1.2. Message Diagram Conventions 🦋
This specification defines the syntax of PB-TNC messages using diagrams. Each diagram shows the format and size of each field in bits. Implementations MUST send the bits in each diagram 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.
Bit field values (like a flag) 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 1-octet field with only bit 0 set has the value 0x80 🔥
1.3. Terminology 🌸
This document reuses the terminology defined in the NEA Requirements document. It defines one new term in this section, so pay attention 🧚
Batch - A group of PB-TNC messages sent over a Posture Transport (PT) protocol at one time. Since the PB-TNC protocol needs to work over a half-duplex PT protocol, PB-TNC messages get grouped into batches. The Posture Broker Client sends one batch to the Posture Broker Server, which responds with a batch 💜
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 [1]. These are the spec's official keywords, so they carry real weight ngl 🫶
2. PB-TNC Design Considerations 🌈
The main job of PB-TNC is to carry Posture Attribute (PA) messages between Posture Collectors and Posture Validators. PB-TNC also has to carry messages between the Posture Broker Client and the Posture Broker Server (these are the PB-TNC messages), and manage the state of the assessment. Lowkey the whole protocol lives or dies on this 🍓
2.1. Message Addressing 🧚
The NEA Overview and Requirements document [8] describes, in section 5.1.1.1, several ways that messages can be addressed and delivered to the proper Posture Collector(s) and Posture Validator(s). Of the techniques in that section, PB-TNC supports dynamic identifiers and message types ✨
2.1.1. Message Types
okay so message types are literally the simplest and most common way to get a message delivered 💅 Every PA message sent via PB-TNC has an associated PA message type, made up of a PA Message Vendor ID and a PA subtype 🎀
The PA-TNC specification [10] has a list of IETF Standard PA Subtypes, and those get used with a PA Message Vendor ID of 0 ✨ They include stuff like Operating System and Anti-Virus, which are for messages about operating system and anti-virus posture 🦋
Vendor-specific PA message types work like this: you put the defining vendor's Structure of Management Information (SMI) Private Enterprise Number into the PA Message Vendor ID field, and then a PA Subtype value that the vendor assigned goes in the PA Subtype field 🌸 This lets each vendor make its own set of PA Subtype values without worrying about collisions with other vendors or with the standard values 🙈
The PA message type is kinda like a MIME type, bc it tells you what kind of PA message you're looking at 🧚 Posture Collectors and Posture Validators can use local APIs to tell the Posture Broker Client and Posture Broker Server which PA message types they're interested in receiving. For example, a Posture Validator that evaluates anti-virus posture might want PA messages with a PA Message Vendor ID of 0 and a PA Subtype that matches the IETF Standard PA Subtype for Anti-Virus. It might also ask for some vendor-specific PA message types to get extra vendor-specific info on anti-virus posture 🔥
This type-based subscription model is giving flexibility in design and implementation 👑 One Posture Validator may be responsible for several functions, like anti-virus and host-based firewall, for instance. Posture Collectors don't need to know which Posture Validators are installed on the Posture Broker Server or what they handle 💖 The Posture Collector just sends PA messages with message types, and the Posture Broker Server delivers them to the right Posture Validators 🫶
Because the Posture Broker Client and Posture Broker Server need access to the PA Message Vendor ID and PA Subtype fields, and because these are routing identifiers that don't depend on the contents of the PA messages, these fields live in PB-TNC and not inside the PA messages themselves 🎀
A similar type-based system is used to tag PB-TNC messages 🍓 Here the extensibility benefits aren't as essential as they are with PA-TNC messages, but being able to define IETF Standard PB-TNC Message Types and vendor-specific PB-TNC message types is still valuable 💜
2.1.2. Dynamic Identifiers
The type-based message delivery model described above isn't ideal for every situation 🙈 Sometimes it matters that a Posture Collector delivers a message to one particular Posture Validator. For example, a particular Posture Validator might send a remediation message, and the Posture Collector might need to send a response only to that one Posture Validator. To handle this, PB-TNC provides delivery based on dynamic identifiers ⭐
When a Posture Broker Server loads a Posture Validator, it assigns that Posture Validator a Posture Validator ID. Any PA messages sent by a Posture Validator include its Posture Validator ID in the Posture Validator ID field of the PB-PA message. A Posture Collector that receives such a message can send a message in response and request exclusive delivery to the Posture Validator identified by that Posture Validator ID ✨
Dynamic identifiers avoid problems caused by the multicast nature of message types. Multiple Posture Collectors or Posture Validators may be registered for the same message type, and that can cause confusion if they all respond and the software designer didn't consider that possibility 💀 The dynamic identifier system allows more directed responses, but it doesn't work until at least one message has been received (so that the dynamic identifiers can be received). Static identifiers were considered as another alternative but rejected, because they result in a brittle system that only works with a particular set of Posture Collectors and Posture Validators, and it causes problems if two Posture Collectors or Posture Validators with the same static identifier are installed 😭
2.2. Vendor IDs
In several places PB-TNC needs to define a set of standard values but also allow vendor-specific extensions 🌈 In each of these places (PB-TNC Message Types, PA Subtypes, Remediation Parameters Types, and Error Codes), the solution chosen was to preface the values with a vendor ID. If a vendor ID is 0, the values in the next field are registered in an IANA registry and their meanings are defined in an RFC. If a vendor ID is non-zero, the values in the next field are vendor specific and defined by the vendor whose SMI Private Enterprise Number matches the vendor ID. Vendor-specific messages that are not understood by the recipient are ignored and skipped unless they have the NOSKIP flag set, in which case an error code is returned 🫠
2.3. Efficiency
PB-TNC needs to work with low bandwidth transports and low power devices 🔋 So a simple, compact format was chosen: binary messages with a Type-Length-Value structure ✨
3. PB-TNC Protocol Description
3.1. Protocol Overview
The PB-TNC protocol carries batches of PB messages between a Posture Broker Client and a Posture Broker Server. It encapsulates PA messages and manages the NEA session. It runs over a PT protocol 🦋
In order to work well over half-duplex PT protocols (such as those based on EAP [9]), PB-TNC supports half-duplex protocol operation. In this mode, the Posture Broker Client and Posture Broker Server take turns sending a single batch of messages to each other. The half-duplex nature could slow down exchanges that need lots of round trips or bidirectional multimedia exchanges, but this isn't a problem in practice, because endpoint assessments don't typically involve multimedia or a large number of round trips. The benefit of working over half-duplex transports outweighs the limitations imposed 💅
PB-TNC also supports full-duplex protocol operation so that PB-TNC exchanges can be re-initialized immediately when needed (e.g., if the Posture Broker Server policy changes or if the Posture Broker Client detects a suspicious event) 👀
Each PB-TNC batch consists of a header followed by a sequence of PB-TNC messages. Each PB-TNC message has a Type-Length-Value (TLV) format with a few flags. The TLV format allows a recipient to skip messages that it does not understand. The TLV format also provides a standard way to mark messages as mandatory, to ensure interoperability between a Posture Broker Client and a Posture Broker Server 🤝
This specification defines certain standard PB-TNC message types. It also permits vendors to define their own vendor-specific message types. One of the most important standard PB-TNC message types is PB-PA. A message with this type contains a PA message and various message routing information. A Posture Broker Client or Posture Broker Server that receives such a message does not interpret the PA message within. Instead, it delivers the PA message to the appropriate set of Posture Collectors or Posture Validators, as determined using the message routing information contained in the PB-PA message 🎀
A Posture Broker Server will often need to communicate with several Posture Broker Clients at once. The reverse may also be true, as when an endpoint has multiple network interfaces connected to different networks. Each connection between a Posture Broker Server and a Posture Broker Client is instantiated as a separate PB-TNC session. There may be several simultaneous sessions between a single Posture Broker Server and Posture Broker Client, but this is unusual 🌸
3.2. PB-TNC State Machine ✨
okay bestie, let's talk about the PB-TNC state machine 🦋 Figure 1 shows every state a PB-TNC session can be in and every transition between them. The paragraphs after it walk through the whole thing, so don't panic if the diagram looks like spaghetti at first 💀
Receive CRETRY SRETRY
or SRETRY +----------------+
+--+ | |
v | v |
+---------+ CRETRY +---------+
CDATA | Server |<---------| Decided | CLOSE
+----------->| Working |--------->| |-------+
| +---------+ RESULT +---------+ |
| ^ | | v
| | | +---------------------->=======
======== | | CLOSE " End "
" Init " CDATA| |SDATA =======
======== | | ^ ^
| | | v | |
| | SDATA +---------+ CLOSE | |
| +-------->| Client |----------------------+ |
| | Working | |
| +---------+ |
| | ^ |
| +--+ |
| Receive CRETRY |
| CLOSE |
+--------------------------------------------------+
Figure 1: PB-TNC state machineStates are the rectangular boxes 📦 The initial and terminal states get double outlines (= and "), and transitions are unidirectional arrows labeled with whatever caused them. So the label tells you why the jump happens, iykyk 💅
Lots of transitions (CDATA, SDATA, CRETRY, SRETRY, and RESULT) fire when a PB-TNC batch of a certain type gets sent or received. The type lives in the Batch Type field of that batch's PB-TNC header 🎀 To keep things snappy, this document says "a FOO batch" instead of "a PB-TNC batch whose Batch Type field contains FOO", which is very iconic of it. Other transitions fire when you receive a certain batch type, like Receive CRETRY. The CLOSE transition can happen when you send or receive a CLOSE batch, but it can also happen when the underlying PT connection just dies 😭
A session starts in Init once the underlying transport protocol (PT) sets up a connection between a Posture Broker Client and a Posture Broker Server 🌸 If the client started the transport session, it sends a CDATA batch to the server, which moves things to Server Working. If the server started the transport session, it sends an SDATA batch to the client, which moves things to Client Working.
From there they take turns, with CDATA and SDATA batches going back and forth. When the session is in Client Working, only the Posture Broker Client can send a data batch. When it's in Server Working, only the Posture Broker Server can.
The most common way to wrap up an exchange is for the server to send a RESULT batch, which lands the session in Decided. Decided is not a terminal state, so the PT session can stay open and the client can start another exchange by sending a CRETRY batch 🧚 This is handy when the client (or, more likely, a Posture Collector) spots something suspicious on the endpoint. If the PT supports full-duplex operation, the server can also kick off another exchange from Decided by sending an SRETRY batch, which is useful when the policy changes on the server.
Whether an SRETRY, a CRETRY, or both get sent, the next state is Server Working. From there the server sends an SDATA batch and the new exchange begins ✨ The transitions labeled Receive CRETRY and Receive CRETRY or SRETRY show that it's totally allowed to receive those messages in those states. This usually happens when the client sends a CRETRY at roughly the same moment the server decides to send an SRETRY. So a CRETRY can show up while you're in Server Working or Client Working, and an SRETRY can show up while you're in Server Working. These messages are redundant, so they get ignored, and those transitions don't cause a state change 🙈
The only terminal state is End. You end up there when the underlying PT connection closes, whether that's because the client or server did something or because of some outside force, like someone yanking the network plug 🔌
When possible, a CLOSE batch SHOULD be sent before the underlying PT connection is terminated. But sometimes there's no warning at all. A plug might get pulled, a program might crash, or the client or server might be unable to send a CLOSE because of half-duplex limits in the PT protocol. In those cases, the client and server will usually get some kind of notification from the Posture Transport Client and Posture Transport Server that the PT connection closed, and that notification can trigger the CLOSE transition. The catch is that how that notification works isn't standardized, since the vertical interfaces in the NEA Reference Model aren't standardized either 🥲 Either way, receiving a CLOSE batch or being told the transport terminated sends you to End.
Also, the client and server won't always have exactly the same state for a given PB-TNC session. Say the session is in Client Working and the Posture Broker Client transmits a CDATA batch. While that batch is in transit (sent by the client but not yet received by the server), the client thinks the session is in Server Working, but the server still thinks it's in Client Working. It's a temporary thing and doesn't cause problems in practice 💖 The only real wrinkle is that a client or server can't know whether the other side got its message until it hears back.
If a half-duplex transport is in use, the server cannot send an SRETRY batch while the session is in Decided. It sent the most recent batch (the RESULT batch), and sending an SRETRY would break the half-duplex nature of the transport protocol 😤 Instead, a server that wants to start a new exchange from Decided should close the PT connection without sending a CLOSE batch and then start a new PB-TNC session. This limitation doesn't exist when a full-duplex transport is used.
And the big rule: the Posture Broker Server and Posture Broker Client MUST follow the state machine described in this section 👑
3.3. Layering on PT
PB-TNC batches get carried over protocol bindings of the PT protocol, which handles the interaction between a Posture Transport Client and a Posture Transport Server 🎀 PB-TNC counts on PT to be a secure transport. Specifically, PT MUST support mutual authentication of the Posture Transport Client and the Posture Transport Server, confidentiality and integrity protection for PB-TNC batches, and protection against replay attacks 🔒 PB-TNC doesn't know which underlying transport protocols are being used, and it operates directly on PT. No extra PB-TNC layer is expected on top of that, so it's just PB-TNC straight on PT 💅
3.3.1. Posture Transport (PT) Protocol Requirements Addendum
RFC 5209 [8] describes the normative requirements for the Posture Transport protocol 📚 This section adds some extra requirements on top of those. Candidate Posture Transport protocols must indicate conformance to the requirements in this section as well as section 7.4 of RFC 5209.
Here are the additional requirements for candidate PT protocols:
PT-6The PT protocol MUST be connection oriented; it MUST support confirmed initiation and close down.PT-7The PT protocol MUST be able to carry binary data.PT-8The PT protocol MUST provide mechanisms for flow control and congestion control.PT-9PT protocol specifications MUST describe the capabilities that they provide for and limitations that they impose on the PB protocol (e.g., half/full duplex, maximum message size).
3.4. Example of PB-TNC Encapsulation
This section shows how PA messages can be carried inside a PB-TNC batch that's inside a PT protocol 🧁 Inside the PT protocol, the PB-TNC header gets packaged next, followed by two PB-PA messages. Those contain PA messages meant for the Posture Collectors and Posture Validators on the platform.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PT Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-PA Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-PA Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Example of PB-TNC message encapsulationThis figure is conceptual, of course, and not an exact byte-for-byte replica 🤓
4. PB-TNC Protocol Specification ✨
This section defines the syntax and semantics of the PB-TNC protocol fields 🌈 If a Posture Broker Client or Posture Broker Server receives a batch that violates the requirements of this specification, it MUST respond by sending a fatal Invalid Parameter error in a CLOSE batch, unless this document specifies otherwise 💀
4.1. PB-TNC Header ✨
okay bestie, every PB-TNC batch MUST start with the following header 🎀. A PB-TNC batch MUST contain only one instance of this header, followed by zero or more PB-TNC messages. The PB-TNC messages are defined in subsequent sections of this specification 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |D| Reserved | B-Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Batch Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Version (8 bits)
This field indicates the version of the format for the PB-TNC message 💅 The whole point is to let evolution of the PB-TNC protocol happen in a way that message recipients can easily detect ✨
This field MUST be set to 2 when the batch conforms to this specification. Later versions of PB-TNC may define other values for this field. The values 0x00, 0x09, 0x0a, 0x0d, 0x20, and 0x3c are reserved and cannot be used for any version of PB-TNC, so PB-TNC can be easily distinguished from earlier posture broker protocols already in use 🌸
If a Posture Broker Client or Posture Broker Server receives a Version value that it does not support, it MUST respond with a PB-TNC batch with batch type CLOSE that contains only a fatal Version Not Supported error code, and whose Version header field has the value 2. 💀 Implementations responding to a PB-TNC message containing a supported version MUST use the same Version number to minimize the risk of version incompatibility. PB-TNC message initiators that support multiple PB-TNC protocol versions SHOULD be able to alter which version of PB-TNC message they send based on prior message exchanges with a particular peer Posture Broker Client or Posture Broker Server 🫶
Directionality (D) (1 bit)
When a Posture Broker Client is sending this message, the Directionality bit MUST be set to 0. When a Posture Broker Server is sending this message, the Directionality bit MUST be set to 1. This is how we avoid any situation where two Posture Broker Clients or two Posture Broker Servers engage in a dialog 🙈 It also helps with debugging, which is giving organized 🧚
Reserved (19 bits)
This field is reserved. For this version of this specification, it MUST be set to 0 on transmission and ignored on reception. Future versions of this specification may allow senders to set some of these bits and recipients to interpret them 🍓
B-Type (Batch Type) (4 bits)
This field is used to drive the state machine described in section 3.2 🔥 This field MUST have one of the values from the following table. If any other value is received, the recipient MUST ignore the contents of the batch and send a fatal Invalid Parameter error code in a CLOSE batch. If the value received is not permitted for the current state, according to the state machine in section 3.2., the recipient MUST ignore the contents of the batch and send a fatal Unexpected Batch Type error code in a CLOSE batch 👑
Number Name Definition
------ ---- ----------
1 CDATA The Posture Broker Client may send a batch with
this Batch Type to convey messages to the
Posture Broker Server. A Posture Broker Server
MUST NOT send this Batch Type. A CDATA batch
may be empty (contain no messages) if the
Posture Broker Client has nothing to send.
2 SDATA The Posture Broker Server may send a batch with
this Batch Type to convey messages to the
Posture Broker Client. A Posture Broker Client
MUST NOT send this Batch Type. An SDATA batch
may be empty (contain no messages) if the
Posture Broker Server has nothing to send.
3 RESULT The Posture Broker Server may send a batch with
this Batch Type to indicate that it has
completed its evaluation. The batch MUST
include a PB-Assessment-Result message and MAY
include a PB-Access-Recommendation message.
4 CRETRY The Posture Broker Client may send a batch with
this Batch Type to indicate that it wishes to
restart an exchange. A Posture Broker Server
MUST NOT send this Batch Type. A CRETRY batch
may be empty (contain no messages) if the
Posture Broker Client has nothing else to send.
5 SRETRY The Posture Broker Server may send a batch with
this Batch Type to indicate that it wishes to
restart the exchange. A Posture Broker Client
MUST NOT send this Batch Type. A SRETRY batch
may be empty (contain no messages) if the
Posture Broker Server has nothing else to send.
6 CLOSE The Posture Broker Server or Posture Broker
Client may send a batch with this Batch Type to
indicate that it is about to terminate the
underlying PT connection. A CLOSE batch may be
empty (contain no messages) if there is nothing
to send. However, if the termination is due to a
fatal error, then the CLOSE batch MUST contain a
PB-Error message.Batch Length (32 bits)
This length field contains the size of the full PB-TNC batch in octets 📏 This length includes the PB-TNC header and all the PB-TNC messages in the batch. In other words, it includes the entire contents of the batch. This field MUST contain at least the value 8 for the fixed-length fields in this header. Any Posture Broker Client or Posture Broker Server that receives a PB-TNC message with a PB-TNC Message Length field whose value is less than 8 MUST respond with a fatal Invalid Parameter error code in a CLOSE batch 💖
4.2. PB-TNC Message ✨
okay bestie, every PB-TNC message has the same overall shape 🎀 The only thing that changes is what goes in the PB-TNC Message Value field, and that depends on the PB-TNC Vendor ID and PB-TNC Message Type fields. so let's look at the layout first 👀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | PB-TNC Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Message Value (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Flags (8 bits) 🚩
this field holds flags that change how the message gets processed 💅
Bit 0 of this Flags field (the most significant bit) is the NOSKIP flag 🔥 if it's cleared (value 0), the recipient (a Posture Broker Client or Posture Broker Server) is allowed to skip, aka ignore, this message if the message type isn't understood, or if the recipient can't or won't process it the way the definition of that message says. if it's set (value 1), then recipients MUST NOT skip this attribute. no skipping, periodt 😭
the NOSKIP flag doesn't mean every recipient has to support the message. what it does mean is that any recipient who gets a message with this flag set to 1, but can't or won't process it as required, MUST NOT act on any part of the PB-TNC batch. instead, the recipient MUST respond with a fatal Unsupported Mandatory Message error code in a CLOSE batch 💀
tip from your bestie 🫶: to avoid acting on half a batch and then finding a NOSKIP message you can't support, recipients of a PB-TNC batch might choose to scan every message in the batch before acting on any of them. they check whether one of them is an unsupported message with the NOSKIP flag set. smart, right? 🧠
the other bits in this Flags field are reserved. for this version of PB-TNC, they MUST be set to 0 on transmission and ignored on reception 🌸
PB-TNC Vendor ID (24 bits) 🏢
the PB-TNC Vendor ID field identifies a vendor using the SMI Private Enterprise Number (PEN) 🦋 any organization can get its own unique PEN from IANA, the Internet Assigned Numbers Authority. this Vendor ID qualifies the PB-TNC Message Type field, so each vendor gets 2^32-1 separate message types to use 🌈
message types standardized by the IETF use zero (0) in this field. the Vendor ID 0xffffff is reserved. Posture Broker Clients and Posture Broker Servers MUST NOT send messages where the Vendor ID has this reserved value (0xffffff). if a Posture Broker Client or Posture Broker Server receives a message where the PB-TNC Vendor ID has this reserved value (0xffffff), it MUST respond with a fatal Invalid Parameter error code in a CLOSE batch 🙈
PB-TNC Message Type (32 bits) 🎯
the PB-TNC Message Type field tells you what kind of PB-TNC message is inside the PB-TNC Message Value field ✨ the message type 0xffffffff is reserved. Posture Broker Clients and Posture Broker Servers MUST NOT send messages where the PB-TNC Message Type field has this reserved value (0xffffffff). if one of them receives a message with this reserved value (0xffffffff), it MUST respond with a fatal Invalid Parameter error code in a CLOSE batch. unless the definition of a particular PB-TNC message type says otherwise (for example, PB-Language-Preference), a single PB-TNC batch can hold multiple messages with the same message type and/or vendor ID 💜
the IETF and any other organization with a PEN can define 2^32-1 unique PB-TNC message types, as long as the organization's PEN goes in the PB-TNC Vendor ID field of the message. since the message type is qualified by the vendor ID, there's no risk of conflicts as long as each organization uses its own PEN for the vendor ID and manages its own set of 2^32-1 message type values. no clashes, no drama 💅
this document defines certain PB-TNC message types that, when used with the IETF SMI PEN (0), have standard meanings. these are known as IETF Standard PB-TNC Message Types 👑 some of them are mandatory, so they MUST be implemented by all Posture Broker Client and Posture Broker Server implementations that claim compliance with this specification. for details on which message types are mandatory, check out the description of these message types later in section 4 🔍
IANA keeps a registry of PB-TNC message types. entries get added by Expert Review with Specification Required, following the guidelines in section 6.1 📋
new vendor-specific PB-TNC message types (the ones used with a non-zero PB-TNC vendor ID) can be defined and used by vendors without any IETF or IANA involvement. even so, Posture Broker Clients and Posture Broker Servers MUST NOT require support for particular vendor-specific PB-TNC message types, and they MUST interoperate with other parties despite any differences in the vendor-specific PB-TNC message types they support. (they MAY let administrators configure them to require support for specific PB-TNC message types, though 🎀)
quick but important: the PB-TNC Message Type field is completely separate from the PA Subtype field 🫠 the same value (for example, 0) can mean one thing as a PB-TNC message type and something else as a PA subtype. don't mix them up, bestie!
PB-TNC Message Length (32 bits) 📏
this field says how long this PB-TNC message is, in octets 🧚 it includes the header (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length). so this value MUST always be at least 12. any Posture Broker Client or Posture Broker Server that gets a message with a PB-TNC Message Length less than 12 MUST respond with a fatal Invalid Parameter error code in a CLOSE batch 🚫
PB-TNC Message Value (variable length) 🍓
the syntax and semantics of this field change depending on the values in the PB-TNC Vendor ID and PB-TNC Message Type fields 🌈 the syntax and semantics of several standard messages get defined in the later sections of this specification 🦋
4.3. IETF Standard PB-TNC Message Types 👑
here's a quick reference table 💖 it has short descriptions of the IETF Standard PB-TNC Message Types defined in this specification. these message types must be used with a PB-TNC vendor ID of zero (0). if these values show up with a different PB-TNC vendor ID, they mean something totally different that this specification doesn't define 😬
Message Type Definition
------------ ----------
0 PB-Experimental - reserved for experimental use
1 PB-PA - contains a PA message
2 PB-Assessment-Result - the overall assessment result
computed by the Posture Broker Server
3 PB-Access-Recommendation - includes Posture Broker
Server access recommendation
4 PB-Remediation-Parameters - includes Posture Broker
Server remediation parameters
5 PB-Error - error indicator
6 PB-Language-Preference - sender's preferred
language(s) for human-readable strings
7 PB-Reason-String - string explaining reason for
Posture Broker Server access recommendationfor more details on these message types, keep reading through the rest of section 4 📖 and for IETF Standard PA Subtypes (which are totally different from PB-TNC message types), check the PA-TNC specification [10] 🧠
4.4. PB-Experimental 🧪
PB-Experimental is a PB-TNC message type (value 0) that's been set aside for experiments 🔬 you can use it to test code or for other experimental stuff. but it MUST NOT be used in a production environment or in a product 🚨 this meaning only applies if the PB-TNC Vendor ID field in the PB-TNC Message Header contains zero (0). if a different Vendor ID is in that field, the PB-TNC message type 0 has a completely different meaning that isn't defined in this specification 🙃
the contents of the PB-TNC Message Length and PB-TNC Message Value fields for this message type aren't specified. they can have almost any value, depending on what experiments are running 🎲 the Flags field for this message can also have the NOSKIP bit set or cleared, depending on the experiment. but heads up: the PB-TNC Message Length field must have a value of at least 12, since that's the total length of the fixed-length fields at the start of the PB-TNC message (Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length). any Posture Broker Client or Posture Broker Server that gets a message with an invalid PB-TNC Message Length field MUST respond with a fatal Invalid Parameter error code in a CLOSE batch ⚠️
a Posture Broker Client or Posture Broker Server implementation meant for production use MUST NOT send a message with this Message Type where the vendor ID is zero (0). if it gets a message with this message type and a vendor ID of zero (0), it MUST ignore the message unless the NOSKIP bit is set. in that case, it MUST respond with a fatal Unsupported Mandatory Message error code in a CLOSE batch 🔥
4.5. PB-PA 📦
the PB-TNC message type named PB-PA (value 1) carries one PA message 💌 lots of batches will have several PB-PA messages, but some batches might not have any of this type at all 🌸
all Posture Broker Client and Posture Broker Server implementations MUST implement support for this PB-TNC message type 💖 usually that support means forwarding the enclosed PA message to the right Posture Collectors and Posture Validators. the specific requirements are in the later description of this message type 📝
the type of the PA message inside a PB-PA message is shown by the PA Message Vendor ID and PA Subtype fields, which get covered later in this section 🦋 the PA-TNC specification [10] describes several standard PA message types that you can identify with the PA Message Vendor ID and PA Subtype values listed there. other PA message types can also be defined, as described under the PA Subtype field later in this section ✨
the NOSKIP flag in the PB-TNC Message Header MUST be set for this message type 🚩 any Posture Broker Client or Posture Broker Server that gets a PB-PA message with the NOSKIP flag not set MUST ignore that message and MUST respond with a fatal Invalid Parameter error code in a CLOSE batch 😭
Okay so picking up right where PB-PA left off 💅 For the PB-PA message type, the PB-TNC Vendor ID field MUST be zero (0) 🫶 and the PB-TNC Message Type field MUST be 1. If the Vendor ID is non-zero, message type 1 means something totally different, and this spec doesn't define it 💀
The PB-TNC Message Length field MUST hold the length of the whole PB-TNC message 🎀 That includes the fixed-length fields at the start (Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length), the fixed-length fields listed below (Flags, PA Message Vendor ID, PA Subtype, Posture Collector Identifier, and Posture Validator Identifier), and the PA Message Body. The PA Message Body is variable length, so this number changes too. It MUST always be at least 24 to cover those fixed-length fields 🌸 If a Posture Broker Client or Posture Broker Server gets a PB-PA message with an invalid PB-TNC Message Length, it MUST respond with a fatal Invalid Parameter error code in a CLOSE batch. Not a vibe ❌
Here's the layout of the PB-TNC Message Value field for this message type 🧚 The text after the diagram explains each field.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | PA Message Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Posture Collector Identifier | Posture Validator Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA Message Body (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Flags (8 bits) 🦋
This field holds flags about the PA message 🌈
Bit 0 of this flags field (the most significant bit) is the EXCL flag (for exclusive) 👑 If EXCL is cleared (value 0), the Posture Broker Client or Posture Broker Server that receives this PB-TNC message SHOULD deliver the PA message to every Posture Collector or Posture Validator that has shown interest in PA messages with this PA Message Vendor ID and PA subtype. If a Posture Broker Client gets a message with EXCL set (value 1), it SHOULD deliver the PA message only to the Posture Collector named in the Posture Collector Identifier field. BUT if that Posture Collector hasn't shown interest in PA messages with this PA Message Vendor ID and PA subtype, the PA message should be silently discarded 🙈 Analogous requirements apply to a Posture Broker Server that receives a message with EXCL set.
The EXCL bit lets a Posture Validator handle a situation like this: there are two Posture Collectors on the endpoint that are both interested in a certain kind of PA message, and the Posture Validator has remediation instructions that only apply to one of them 😭 Main character energy for the bit, honestly.
The other bits in this Flags field are reserved. In this version of PB-TNC, they MUST be set to 0 on transmission and ignored on reception 🍓
PA Message Vendor ID (24 bits) 💜
The PA Message Vendor ID field identifies a vendor using the SMI Private Enterprise Number (PEN). Any organization can get its own unique PEN from IANA, the Internet Assigned Numbers Authority ✨ This field qualifies the PA Subtype field, so each vendor gets 2^32-1 separate PA subtypes to use. PA subtypes standardized by the IETF are always sent with a PA Message Vendor ID of zero (0). The PA Message Vendor ID 0xffffff is reserved. A Posture Broker Client or Posture Broker Server MUST NOT send messages where the PA Message Vendor ID is this reserved value (0xffffff). If a Posture Broker Client or Posture Broker Server receives a message where the PA Message Vendor ID is 0xffffff, it MUST respond with a fatal Invalid Parameter error code in a CLOSE batch 🚫
PA Subtype (32 bits) 🌟
The PA Subtype field identifies the type of the PA message in the PA Message Body field. The PA subtype 0xffffffff is reserved. A Posture Broker Client or Posture Broker Server MUST NOT send messages where the PA Subtype field is this reserved value (0xffffffff). If one of them receives a message where the PA Subtype is 0xffffffff, it MUST respond with a fatal Invalid Parameter error code in a CLOSE batch. Also, a Posture Broker Client or Posture Broker Server MUST support having multiple PA messages in a single PB-TNC batch that share the same PA subtype and/or PA Message Vendor ID 🫶
IANA keeps a registry of PA subtypes 📋 Entries get added by Expert Review with Specification Required, following the guidelines in section 6.1. No PA subtypes are defined in this specification. Definitions of IETF Standard PA Subtypes live in the PA-TNC specification [10] and other specifications. IETF Standard PA Subtypes always use a PA Message Vendor ID of zero (0).
Vendor-specific PA subtypes (the ones used with a non-zero PA Message Vendor ID) can be defined and used by vendors without any IETF or IANA involvement 💅 Still, Posture Broker Clients and Posture Broker Servers MUST NOT require support for particular vendor-specific PA subtypes, and MUST interoperate with other parties despite differences in which vendor-specific PA subtypes they support (although they MAY let administrators configure them to require support for specific PA subtypes). Teamwork makes the dream work 🌸
Quick reminder: the PB-TNC Message Type field is totally separate from the PA Subtype field 🙃 The same value (e.g., 0) can mean different things as a PB-TNC message type and as a PA subtype. Don't mix them up, bestie 😭
Posture Collector Identifier (16 bits) 🎀
The Posture Collector Identifier field holds the identifier of the Posture Collector linked to this PA message.
The Posture Broker Client is responsible for assigning one or more Posture Collector Identifier values (but not 0xffff) to each Posture Collector in a message exchange 🧚 Multiple identifiers matter for correlation when a single Posture Collector handles several components of the same type. For example, an endpoint with two VPN client implementations handled by one VPN Posture Collector. Check out section 3.3 of the PA-TNC specification for an example using multiple Posture Collector Identifiers. Once a Posture Broker Client assigns a Posture Collector Identifier value to a Posture Collector, that value MUST NOT change during the course of a PT session. This identifier is how the Posture Validator tells apart one Posture Collector talking to the Posture Broker Client on the endpoint during a NEA exchange, and it's used to send response attributes to a specific Posture Collector component when needed 🔥
When a Posture Broker Server sets the EXCL flag for a PA message, it MUST set the Posture Collector Identifier field to the identifier of the Posture Collector that should receive the PA message 👑 If EXCL isn't set, a Posture Broker Server MAY still set the Posture Collector Identifier value on PA messages it sends, to show that the PA message is a response to a message from the Posture Collector with that identifier. If the Posture Broker Server doesn't want to point at any Posture Collector like this, it SHOULD set this field to the reserved value 0xffff ✨
Posture Validator Identifier (16 bits) 🌈
The Posture Validator Identifier field holds the identifier of the Posture Validator linked to this PA message.
The Posture Broker Server MUST assign a unique Posture Validator Identifier value (but not 0xffff) to each Posture Validator in a message exchange, and it MUST put that identifier in this field for any PA messages that Posture Validator sends 💖 The value assigned to a Posture Validator by a Posture Broker Server MUST NOT change during the course of a PT session. This identifier tells apart a unique Posture Validator communicating with the Posture Broker Server endpoint during a NEA exchange, and the Posture Collector uses it to send attributes to a specific Posture Validator when needed 🦋
When a Posture Broker Client sets the EXCL flag for a PA message, it MUST set the Posture Validator Identifier field to the identifier of the Posture Validator that should receive the PA message 🫶 If EXCL isn't set, a Posture Broker Client MAY still set the Posture Validator Identifier value on PA messages it sends, to show the PA message is a response to a message from the Posture Validator with that identifier. If the Posture Broker Client doesn't want to point at any Posture Validator like this, it SHOULD set this field to the reserved value 0xffff 🍓
PA Message Body (variable length) 🌸
The PA Message Body field carries the body of the PA message inside this PB-TNC message 💅 You can work out its length by taking the fixed-length fields at the start of the PB-TNC message (Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length) and the fixed-length fields at the start of the PB-PA message (Flags, PA Message Vendor ID, PA Subtype, Posture Collector Identifier, and Posture Validator Identifier) away from the length in the PB-TNC Message Length field. Those fixed-length fields add up to 24 octets, so any Posture Broker Client or Posture Broker Server that gets a PB-PA message with a PB-TNC Message Length value less than 24 MUST respond with a fatal Invalid Parameter error code in a CLOSE batch 💀 Don't skip the length check, bestie 🙏
4.6. PB-Assessment-Result 💅
okay bestie, the PB-TNC message type called PB-Assessment-Result (value 2) is how the Posture Broker Server 👑 tells everyone the final verdict after it's finished assessing the endpoint 🫶. Usually the server builds that verdict by combining the individual results it got from all the different Posture Validators 🦋. How it does that math at the Posture Broker layer is up to each implementation, and it can even change depending on the policies in a particular deployment 🎀.
The Posture Broker Server MUST include one message of this type in any batch of type RESULT, and it MUST NOT include one in any other type of batch 💖. The Posture Broker Client MUST NOT send a PB-TNC message with this message type 🙈. If a Posture Broker Server gets a PB-TNC message with this message type, it MUST respond with a fatal Invalid Parameter error in a CLOSE batch 💀. The Posture Broker Client MUST implement and process this message, and it MUST ignore any message with this message type that isn't part of a batch of type RESULT ✨.
The NOSKIP flag in the PB-TNC Message Header MUST be set for this message type 🌸. The PB-TNC Vendor ID field MUST contain the value zero (0), and the PB-TNC Message Type field MUST contain 2 🍓. If there's a non-zero value in the PB-TNC Vendor ID field, then message type 2 means something totally different that this specification doesn't define, so it's not this one 🧚. The PB-TNC Message Length field MUST contain the value 16, because that's the total of the fixed-length fields at the start of the PB-TNC message (Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length) plus the Assessment Result field below 🌈. Any Posture Broker Client or Posture Broker Server that receives a PB-Assessment-Result message with a PB-TNC Message Length field that doesn't have a value of 16 MUST respond with a fatal Invalid Parameter error code in a CLOSE batch 🔥.
Here's the layout of the PB-TNC Message Value field for this message type. The text after the diagram explains the fields 🦋.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assessment Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Assessment Result
This 32-bit field MUST contain one of the following values 🎀:
Value Description
----- -----------
0 Posture Broker Server assessed the endpoint to be
compliant with policy.
1 Posture Broker Server assessed the endpoint to be non-
compliant with policy but the difference from compliance
was minor.
2 Posture Broker Server assessed the endpoint to be non-
compliant with policy and the assessed difference from
compliance was very significant.
3 Posture Broker Server was unable to determine policy
compliance due to an error.
4 Posture Broker Server was unable to determine whether the
assessed endpoint is compliant with policy based on the
attributes provided by endpoint.If a Posture Broker Client receives an Assessment Result value that isn't one of those five values, it MUST respond with a fatal Invalid Parameter error in a CLOSE batch 😭. Other values might be defined in future versions of PB-TNC, but only if the PB-TNC version number changes 🌈. So there's no need for an IANA registry for Assessment Result values, bestie 🫶.
4.7. PB-Access-Recommendation ✨
The PB-TNC message type called PB-Access-Recommendation (value 3) is how the Posture Broker Server gives an access recommendation after it has done some assessment of the endpoint 🦋. The PB-Assessment-Result and the PB-Access-Recommendation attribute together make up the global assessment decision for an endpoint, so they're a team 💜. The PB-Access-Recommendation isn't authoritative, though! Network and host-based access control systems would usually look at extra information to decide what network access the endpoint actually gets 🙈.
The Posture Broker Server MAY include one message of this type in any batch of type RESULT, and it MUST NOT include one in any other type of batch 🌸. Posture Broker Clients MUST NOT send a PB-TNC message with this message type 🍓. If a Posture Broker Server receives a PB-TNC message with this message type, it MUST respond with a fatal Invalid Parameter error in a CLOSE batch 💀. The Posture Broker Client MUST implement and process this message, and it MUST ignore any message with this message type that isn't part of a batch of type RESULT 💅.
The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this message type 🧚. If any Posture Broker Client or Posture Broker Server receives a PB-Access-Recommendation message with the NOSKIP flag set, it MUST ignore the message and MUST respond with a fatal Invalid Parameter error code in a CLOSE batch 🔥. The PB-TNC Vendor ID field MUST contain the value zero (0), and the PB-TNC Message Type field MUST contain 3 ✨. If there's a non-zero value in the PB-TNC Vendor ID field, message type 3 has a completely different meaning that isn't defined in this specification 🌈. The PB-TNC Message Length field MUST contain the value 16, since that's the total of the fixed-length fields at the start of the PB-TNC message (Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length) plus the Access Recommendation field below 🎀. Any Posture Broker Client or Posture Broker Server that receives a PB-Access-Recommendation message with a PB-TNC Message Length field that doesn't have a value of 16 MUST respond with a fatal Invalid Parameter error code in a CLOSE batch 💀.
Here's the layout of the PB-TNC Message Value field for this message type. The text after the diagram describes the fields shown here 🦋.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Access Recommendation Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Reserved (16 bits)
These Reserved bits MUST be set to 0 on transmission and ignored on reception 💖.
Access Recommendation Code (16 bits)
The Access Recommendation Code field tells you which Access Recommendation the Posture Broker Server has made for this Posture Broker Client at this time 👑. This field MUST have one of these three values: 1 for Access Allowed (full access), 2 for Access Denied (no access), or 3 for Quarantined (partial access) 🫶. If a Posture Broker Client receives an Access Recommendation Code value that isn't one of these three values, it MUST respond with a fatal Invalid Parameter error code in a CLOSE batch 😭. Other values might be defined in future versions of PB-TNC, but only if the PB-TNC version number changes. So, once again, there's no need for an IANA registry for Access Recommendation Codes 🌸.
4.8. PB-Remediation-Parameters 🎀
okay so the PB-TNC message type named PB-Remediation-Parameters (value 4) is how the Posture Broker Server hands over global remediation parameters (the ones that aren't specific to any one Posture Validator) once it's finished assessing the endpoint 💅. The Posture Broker Server MAY include one or more messages of this type in any batch of any type, but this message type is most useful in batches of type RESULT ✨.
the Posture Broker Client MUST NOT send a PB-TNC message with this message type 🙅♀️. if a Posture Broker Server gets a PB-TNC message with this message type, it MUST respond with a fatal Invalid Parameter error in a CLOSE batch 😭. the Posture Broker Client may implement and process this message but it isn't required to 💖. it can totally skip this message. even if the client does implement it, it's not obligated to act on it 🌸.
the NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this message type 🚫. the PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 4 🍓. if a non-zero value is in the PB-TNC Vendor ID field, then message type 4 has a completely different meaning that this specification doesn't define 👀.
the PB-TNC Message Length field MUST contain the length of the entire PB-TNC message 📏. that includes the fixed-length fields at the start of the PB-TNC message (Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length), the fixed-length fields listed below (Reserved, Remediation Parameters Vendor ID, and Remediation Parameters Type), and the Remediation Parameters themselves 🧚. because the Remediation Parameters field is variable length, the PB-TNC Message Length value will vary too 🦋. but it MUST always be at least 20 to cover those fixed-length fields 💜. any Posture Broker Client that receives a PB-Remediation-Parameters message with an invalid PB-TNC Message Length value (for example, less than 20) MUST respond with a fatal Invalid Parameter error code in a CLOSE batch 🫶.
here's the diagram for the PB-TNC Message Value field for this message type, and the text after it walks through each field 🎀.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Remediation Parameters Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation Parameters Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation Parameters (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Reserved (8 bits) 🌈
these Reserved bits MUST be set to 0 on transmission and ignored on reception 🙈.
Remediation Parameters Vendor ID (24 bits) 🦋
the Remediation Parameters Vendor ID field identifies a vendor using the SMI Private Enterprise Number (PEN) 🏢. any organization can get its own unique PEN from IANA, the Internet Assigned Numbers Authority ✨. the Remediation Parameters Vendor ID qualifies the Remediation Parameters Type field, so each vendor gets 2^32 separate Remediation Parameters Types for its own use 👑. Remediation Parameters Types standardized by the IETF are always used with the value zero (0) in this field 💅.
Remediation Parameters Type (32 bits) 🍓
the Remediation Parameters Type field identifies the kind of remediation parameters carried in the Remediation Parameters field. a Posture Broker Client or Posture Broker Server MUST support having multiple Remediation Parameters messages in a single PB-TNC batch that have the same Remediation Parameters Type and/or Remediation Parameters Vendor ID 🫶.
IANA keeps a registry of PB-TNC Remediation Parameters Types 📚. entries get added by Expert Review with Specification Required, following the guidelines in section 6.1 🔥. a list of IETF Standard PB-TNC Remediation Parameters Types defined in this specification shows up later in this section 💖.
vendors can define brand-new vendor-specific Remediation Parameters Types (the ones used with a non-zero Remediation Parameters vendor ID) on their own, with no IETF or IANA involvement 🧚. still, Posture Broker Clients and Posture Broker Servers MUST NOT require support for particular vendor-specific Remediation Parameters Types 🙅♀️. they MUST interoperate with other parties despite any differences in the set of vendor-specific types they support (although they MAY let administrators configure them to require support for specific Remediation Parameters Types) 🌸.
note that the Remediation Parameters Type is completely separate from the PB-TNC Message Type and the PA Subtype fields 🙈. the same value (e.g., 0) can mean different things in each of these fields 🌈.
Remediation Parameters (variable length) 💜
the Remediation Parameters field has the actual remediation parameters carried in this PB-TNC message. you can work out its length by subtracting the length of the fixed-length fields at the start of the PB-TNC message (Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length) and the fixed-length fields at the start of the PB-Remediation-Parameters message (Reserved, Remediation Parameters Vendor ID, and Remediation Parameters Type) from the message length in the PB-TNC Message Length field 🧮. those fixed-length fields add up to 20 octets ✨. so any Posture Broker Client that receives a PB-Remediation-Parameters message whose PB-TNC Message Length value is less than 20 MUST consider it a malformed message 😭. the Posture Broker Client MUST respond with a fatal Invalid Parameter error code in a CLOSE batch 💀.
4.8.1. IETF Standard PB-TNC Remediation Parameters Types 👑
this subsection defines several Remediation Parameters Types that the IETF has standardized 🦋.
Remediation-URI 🌸
you use this Remediation Parameters Type by creating a PB-Remediation-Parameters message with a Remediation Parameters Vendor ID equal to zero (0) and a Remediation Parameters Type of 1 🎀. the Remediation Parameters field in the PB-Remediation-Parameters message MUST contain a URI, as described in RFC 3986 [2] 🔗. this URI holds instructions and resources for remediation 📖. the Posture Broker Client MAY load the URI and display the resulting web page to the user 🌈. the Posture Broker Client MAY also ignore the URI or take some other action with it 🙃. the Posture Broker Server, and any other parties involved in configuring this remediation URI, should think about the likely capabilities of the Posture Broker Client when they create the URI and the content it points to 🧠. for example, they should consider the Posture Broker Client's language preferences as expressed in the PB-Language-Preference message 🌍.
Remediation-String 💖
you use this Remediation Parameters Type by creating a PB-Remediation-Parameters message with a Remediation Parameters Vendor ID equal to zero (0) and a Remediation Parameters Type of 2 ✨. the Remediation Parameters field in the PB-Remediation-Parameters message MUST contain the structure defined below, which holds human-readable instructions for remediation 📝.
the Posture Broker Client MAY display the instructions to the user 💅. the Posture Broker Client MAY also ignore the instructions or take some other action with them 🫶. the Posture Broker Server, and any other parties involved in configuring these instructions, should think about the likely capabilities of the Posture Broker Client when they write the instructions 🧚. for example, they should consider the Posture Broker Client's language preferences as expressed in the PB-Language-Preference message 🌸.
here's how the Remediation Parameters field looks when it carries a Remediation-String parameter, and the text after it breaks down the fields 🎀.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation String Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation String (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lang Code Len | Remediation String Lang Code (Variable Len) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Remediation String Length (32 bits) 📏
the Remediation String Length contains the length of the Remediation String field in octets 🧁.
Remediation String (variable length) 🌷
the Remediation String field MUST contain a UTF-8 [6] encoded string 💌. this string has human-readable remediation instructions that MAY be displayed to the user by the Posture Broker Client 🙌. NUL termination MUST NOT be included 🚫. if a Posture Broker Client receives a Reason String that does contain a NUL termination, it MUST respond with a fatal Invalid Parameter error in a CLOSE batch 😱.
Lang Code Len (8 bits) 🌍
the Lang Code Len field contains the length of the Remediation String Lang Code field in octets 🔢. this value may be set to zero to say that the language code for the Remediation String field is not known 🤷♀️.
Remediation String Lang Code (variable length) 🗣️
the Remediation String Lang Code field contains a US-ASCII string made of a well-formed RFC 4646 [3] language tag that says which language(s) are used in the Remediation String in the Remediation Parameters field 🌈. a zero-length string may be sent for this field (basically leaving the field out) to say that the language code for the Remediation String field is not known 💜.
4.9. PB-Error 🚨
okay so the PB-TNC message type named PB-Error (value 5) is the "something went wrong!!" message 😭 A Posture Broker Client or Posture Broker Server MAY include one or more of these in any batch of any type, and other messages can ride along in the same batch 🫶 Whoever receives a PB-Error MAY log it or take whatever action makes sense for them 💅 If the FATAL flag is set (value 1), the recipient MUST terminate the PB-TNC session after processing the batch, and it MUST NOT send any messages back in response 💀 Every Posture Broker Client and Posture Broker Server MUST implement this message type, no exceptions bestie ✨
The NOSKIP flag in the PB-TNC Message Header MUST be set for this message type 🔒 The PB-TNC Vendor ID field MUST contain the value zero (0), and the PB-TNC Message Type field MUST contain 5 🍓 If a non-zero value is in the PB-TNC Vendor ID field, then message type 5 has a completely different meaning that this specification does not define, so it's a whole different vibe 🦋
The PB-TNC Message Length field MUST contain the length of the entire PB-TNC message 📏 That includes the fixed-length fields at the start (Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length), the fixed-length fields listed below (Flags, Error Code Vendor ID, Error Code, and Reserved), and the Error Parameters. Since Error Parameters is variable length, the PB-TNC Message Length value will change too 🌈
But it MUST always be at least 20 to cover those fixed-length fields 🧚 Any Posture Broker Client or Posture Broker Server that gets a PB-Error with an invalid PB-TNC Message Length (for example, less than 20) MUST respond with a fatal Invalid Parameter error code in a CLOSE batch 🙈 And any PB-Error generated while processing a PB-Error MUST be a fatal error, so we don't end up in an infinite loop of errors, which would be literally the worst 💀
Here's the diagram for the PB-TNC Message Value field for this message type. The text after it explains the fields 🎀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Parameters (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Flags (8 bits) 🚩
This field defines flags relating to the error ✨
Bit 0 of this flags field (the most significant bit) is known as the FATAL flag 🔥 If the FATAL bit is cleared (value 0), the Posture Broker Client or Posture Broker Server that receives this PB-TNC message SHOULD process the error and then keep going with the exchange 🌸 If the FATAL flag is set (value 1), the receiver MUST terminate the exchange after processing the error 💅 Also, any Posture Broker Client or Posture Broker Server that sends a fatal error MUST NOT process the batch that caused the error, and it MUST terminate the exchange after sending the batch with the error report 👑 A PB-Error with the FATAL flag set MUST always be sent in a CLOSE batch, since the sender is ending the exchange right after 🫶
The FATAL bit lets a Posture Broker Client or Posture Broker Server signal a fatal error (like an invalid batch type) and/or a non-fatal error (like an invalid language tag for a preferred language) 🦋
The other bits in this Flags field are reserved 🔐 For this version of PB-TNC, they MUST be set to 0 on transmission and ignored on reception 💜
Error Code Vendor ID (24 bits) 🏷️
The Error Code Vendor ID field identifies a vendor by using the SMI Private Enterprise Number (PEN) 🌈 Any organization can get its own unique PEN from IANA, the Internet Assigned Numbers Authority 🍓 The Error Code Vendor ID qualifies the Error Code field, so each vendor gets 2^16 separate Error Codes for its own use ✨ Error codes standardized by the IETF are always used with the value zero (0) in this field 🎀 For detailed descriptions of those messages, check out the next few subsections 👀
Error Code (16 bits) 🔢
The Error Code field identifies the type of error being signaled with this message 🚨 The format of the Error Parameters field depends on the Error Code Vendor ID and the Error Code. But any recipient that doesn't understand a particular error code can still handle the error pretty well by using the FATAL flag to tell whether it's fatal, and the PB-TNC Message Length to skip over the Error Parameters field (or just log it) 🧚
IANA maintains a registry of PB-TNC Error Codes 📋 Entries get added by Expert Review with Specification Required, following the guidelines in section 6.1 💼 A list of IETF Standard PB-TNC Error Codes defined in this specification shows up later, in section 4.9.1 👀
New vendor-specific error codes (the ones used with a non-zero error code vendor ID) may be defined and used by vendors without any IETF or IANA involvement 🦋 Posture Broker Clients and Posture Broker Servers that receive an unknown error code MUST handle it gracefully by ignoring or logging it if it's not marked as fatal, and by terminating the exchange if it is marked as fatal 🫶
Reserved (16 bits) 🔐
The Reserved bits MUST be set to 0 on transmission and ignored on reception 💖
4.9.1. IETF Standard PB-TNC Error Codes 📚
The following error codes are IETF Standard PB-TNC Error Codes, so the Error Code Vendor ID MUST be the value zero (0) 🌸 The table below defines the 16-bit error code 🎀 Vendor-specific error codes can be defined by setting the Error Code Vendor ID to the defining vendor's SMI PEN and setting the Error Code field to whatever error code(s) that vendor has defined 💅 The format, length, and meaning of the Error Parameters field varies based on the Error Code Vendor ID and Error Code 🌈 The later sections of this document define the format, length, and meaning of the Error Parameters for the IETF Standard PB-TNC Error Codes listed here ✨
Error Code Definition
---------- ----------
0 Unexpected Batch Type. Error Parameters are empty.
1 Invalid Parameter. Error Parameters has offset where
invalid value was found.
2 Local Error. Error Parameters are empty.
3 Unsupported Mandatory Message. Error Parameters has
offset of offending PB-TNC Message
4 Version Not Supported. Error Parameters has information
about which versions are supported.4.9.2. Error Parameters Structures for IETF Standard PB-TNC Error Codes 🧩
This section defines the format, length, and meaning of the Error Parameters field for the IETF Standard PB-TNC Error Codes defined in this specification 💖
The Error Parameters field is zero length for IETF Standard PB-TNC Error Code 0 🫧 The FATAL flag MUST be set for this error code 🔥
The Error Parameters field has the following structure for IETF Standard PB-TNC Error Code 1 📐 The Offset field is the offset in octets from the start of the PB-TNC batch to the invalid value 🦋 The FATAL flag may be either set or cleared for this error code 🌈
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Error Parameters field is zero length for IETF Standard PB-TNC Error Code 2 🫧 The FATAL flag MUST be set for this error code 🔥
The Error Parameters field has the following structure for IETF Standard PB-TNC Error Code 3 📐 The Offset field is the offset in octets from the start of the PB-TNC batch to the PB-TNC message whose message type wasn't recognized (and where the NOSKIP flag was set) 🙈 The FATAL flag MUST be set for this error code 💅
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Error Parameters field has the following structure for IETF Standard PB-TNC Error Code 4 🌟 The FATAL flag MUST be set for this error code 🔥
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bad Version | Max Version | Min Version | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Bad Version field is the version number that was received and isn't supported 🙅♀️ The Max Version and Min Version fields show which PB-TNC version numbers are supported by the sender of the error code 🎀 The sender MUST support all PB-TNC versions between the Min Version and the Max Version, inclusive (meaning both the Min Version and the Max Version are included), but excluding the reserved versions listed in section 4.1 💖 The Reserved field MUST be set to 0 on transmission and ignored upon reception 🫧 When possible, recipients of this error code SHOULD send future messages to the Posture Broker Server or Posture Broker Client that originated this error message, using a PB-TNC version number within the stated range 🦋
Any party sending the Version Not Supported error code MUST include that error code as the only PB-TNC message in a PB-TNC CLOSE batch with version number 2 🌸 All parties that send PB-TNC batches SHOULD be able to properly process a batch that fits this description, even if they can't process anything else about PB-TNC version 2 🫶 This makes sure a PB-TNC version exchange can go through properly, no matter which versions of PB-TNC the parties implement ✨
4.10. PB-Language-Preference 🌸
okay so the PB-TNC message type called PB-Language-Parameters (value 6) is how the Posture Broker Client tells everyone which language or languages it would prefer for any human-readable strings that might get sent its way 💖 That lets the Posture Broker Server and Posture Validators adapt their messages to the client's preferences (probably determined by the language preferences of the endpoint's users) 🌈
The Posture Broker Server can also send this message type to the Posture Broker Client to share its own language preferences 🧚 It's not super useful though, since the Posture Broker Client rarely sends human-readable strings to the Posture Broker Server, and if it does, it rarely can adapt them to the server's preferences 💅
No Posture Broker Client or Posture Broker Server is required to send or implement this message type. BUT a Posture Broker Server SHOULD try to adapt to user language preferences by implementing this message type, passing the language preference info to Posture Validators, and letting admins configure human-readable languages in whatever languages their users prefer 🫶
A Posture Broker Client or Posture Broker Server may include a message of this type in any batch of any type. It's suggested that it go in the first batch sent in a PB-TNC session so the recipient can start adapting its human-readable messages ASAP ⭐ If one PB-Language-Parameters message is received and then another one shows up in a later batch for the same PB-TNC session, the value in the later message should be considered to replace the value in the earlier one 🦋
A Posture Broker Client or Posture Broker Server MUST NOT include more than one message of this type in a single batch. If a Posture Broker Client or Posture Broker Server receives more than one message of this type in a single batch, it should ignore all but the last one 🙈
The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this message type. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 6. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 6 has a completely different meaning not defined in this specification 👑
The PB-TNC Message Length field MUST contain the length of the entire PB-TNC message, including the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length) and the Language Preference field. Since the Language Preference field is variable length, the value in the PB-TNC Message Length field will vary also. However, it MUST always be at least 12 to cover the fixed-length fields listed in the preceding sentences 🎀
The following diagram shows the format and contents of the PB-TNC Message Value field for this message type. The text after this diagram describes the fields shown here 🍓
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Language Preference (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Language Preference (variable length)
The Language Preference field contains an Accept-Language header, as described in RFC 3282 [4] (using the RFC 2234 ABNF definition of Accept-Language included in that RFC, US-ASCII only, no control characters allowed, no comments, no NUL termination). Any Posture Broker Client or Posture Broker Server that sends a PB-Language-Preference message MUST ensure that the Language Preference field conforms to this format. For example, one acceptable value would be Accept-Language: fr, en (without the quote marks) 🌍
A zero-length Language Preference field indicates that no language preference information is available. Generally, there's no need to send a PB-Language-Preference message with a zero-length Language Preference field, since this is equivalent to sending no PB-Language-Preference message at all. But it may be useful to send a zero-length Language Preference field if a PB-Language-Preference message with a non-zero-length Language Preference field was sent in an earlier batch but these preferences no longer apply 🧹
4.11. PB-Reason-String 💬
The PB-TNC message type named PB-Reason-String (value 7) is used by the Posture Broker Server to provide a human-readable explanation for the global assessment decision conveyed in the PB-Assessment-Result & PB-Access-Recommendation messages. Therefore, a PB-Reason-String message SHOULD only be included in the same batch as the PB-Assessment-Result and PB-Access-Recommendation message. The Posture Broker Client MUST NOT ever send a PB-Reason-String message 🚫
The Posture Broker Client is not required to implement this message type, and the Posture Broker Server is not required to send it. However, there is some benefit to doing so, since users are often curious about why the endpoint was considered non-compliant 🤔 The manner in which a Posture Broker Client uses this field is up to the implementer and not specified here. The Posture Broker Client MAY display the message to the user, log it, ignore it, or take any other action that is not inconsistent with the requirements of this specification. Since the strings contained in this message are human-readable, the Posture Broker Server SHOULD adapt them to the Posture Broker Client's language preferences, as expressed in any PB-Language-Preference message sent by the Posture Broker Client in this PB-TNC session 🫧
A Posture Broker Server MAY include more than one message of this type in any batch of any type. However, it is suggested that this message be included in the same batch as the PB-Assessment-Result and PB-Access-Recommendation message. If more than one PB-Reason-String message is included in a single batch, the Posture Broker Client SHOULD consider the strings included in these messages to be equivalent in meaning. This allows the Posture Broker Server to return multiple equivalent reason strings in different languages, which may help if the Posture Broker Server is not able to accommodate the Posture Broker Client's language preferences 🌷
The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this message type. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 7. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 7 has a completely different meaning not defined in this specification 💅
The PB-TNC Message Length field MUST contain the length of the entire PB-TNC message, including the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length), the fixed-length fields listed below (Reason String Length and Lang Code Len), and the Reason String and Reason String Language Code fields. Since the Reason String and Reason String Language Code fields are variable length, the value in the PB-TNC Message Length field will vary also. However, it MUST always be at least 17 to cover the fixed-length fields listed in the preceding sentences. In fact, the PB-TNC Message Length field MUST be exactly the sum of 17 (for the fixed-length fields) and the values of the Reason String Length and Lang Code Len fields. If this is not the case, the recipient MUST respond with a fatal Invalid Parameter error code in a CLOSE batch 🚨
The following diagram shows the format and contents of the PB-TNC Message Value field for this message type. The text after this diagram describes the fields shown here 🧁
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason String Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason String (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lang Code Len | Reason String Language Code (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Reason String Length (32 bits)
The Reason String Length field contains the length of the Reason String field in octets 📏
Reason String (variable length)
The Reason String field contains a UTF-8 encoded string that provides a human-readable reason for the Posture Broker Server's assessment decision. NUL termination MUST NOT be included. If a Posture Broker Client receives a Reason String that does contain a NUL termination, it MUST respond with a fatal Invalid Parameter error code in a CLOSE batch. A zero-length string MUST NOT be sent, since this is the same as sending no reason string at all, leaving the reason unspecified 🫣
Lang Code Len (8 bits)
The Lang Code Len field contains the length of the Reason String Language Code field in octets 🔢
Reason String Language Code (variable length)
The Reason String Language Code field contains a US-ASCII string containing a well-formed RFC 4646 [3] language tag that indicates the language(s) used in the Reason String in this message. NUL termination MUST NOT be included in this field. A zero-length string MAY be sent for this field (essentially omitting this field) to indicate that the language code for the reason string is not known 🏳️🌈
5. Security Considerations 🛡️
PT is required and assumed to provide reliable and secure transport for the PB-TNC protocol (including authentication, confidentiality, integrity protection, and replay protection). Still, it is useful to describe the possible threats to PB-TNC and the countermeasures that are or can be employed. This section does that 🔐
5.1. Threat Model 🎀
okay bestie, let's talk about who's trying to mess with PB-TNC 😈 (don't worry, we're doing defense 💅). There are several possible threats to the PB-TNC protocol.
Untrusted intermediaries on the network between the NEA Client and the NEA Server might try to observe the data flowing between the Posture Broker Client and the Posture Broker Server via PB-TNC, modify it in transit, reorder it, or replay it. They might also run a denial-of-service attack against either party, or truncate the exchange early 🙈. If they pull any of this off, it gets messy fast: improper assessment decisions about the NEA Client, failure to reassess those decisions when circumstances change, improper remediation instructions sent to the NEA Client (which could lead to the NEA Client getting compromised 😭), unauthorized access to confidential information about the NEA Client's health and/or identity, improper reason strings or other messages that might get shown to the user, access to reusable credentials such as posture assertions, denial of service on the NEA Client, and even a complete cutoff from the network (if a denial-of-service attack against the NEA Server worked and the network needed permission from the NEA Server to grant network access). Literally a nightmare 💀
Trusted intermediaries between the Posture Broker Client and the Posture Broker Server include the Posture Transport Client and the Posture Transport Server. They're considered trusted because they're responsible for properly implementing the security protections provided by PT. If they don't do that properly, those protections can be diminished or eliminated altogether 😬. The possible attacks are the same as the ones in the previous paragraph. Here's a pretty likely example: if a Posture Transport Client fails to properly authenticate and authorize the Posture Transport Server (whether through an implementation error or through user configuration to "trust anyone"), the improperly authorized Posture Transport Server can run any of the attacks we just covered against the NEA Client. Not it 🙅♀️
Compromise of any of the trusted parties (the Posture Broker Client, the Posture Transport Client, the Posture Broker Server, or the Posture Transport Server) can cause failures equivalent to the ones in the first paragraph. These failures can be even more dangerous because they won't be detectable by watching network traffic or by examining and comparing audit logs 👀. Failing to properly secure communications between the Posture Broker Client and the Posture Transport Client, or between the Posture Broker Server and the Posture Transport Server, is usually indistinguishable from compromise of those parties. Compromise of the operating system or other critical software, firmware, or hardware components on the NEA Client or NEA Server will typically have an equivalent result. And an attacker's ability to gain privileged access to the NEA Client or NEA Server (even briefly, long enough to disable or misconfigure security settings) is generally equivalent too. If the NEA Client or NEA Server depends on other services for proper operation (including Posture Collectors, Posture Validators, directories, and patch management services), compromise of those services can lead to compromise or failure of the dependent parties. Of course, compromise or failure of NEA Server components is the most serious, since it would probably affect a large number of NEA Clients, while the effects of NEA Client compromise might well be limited to a single machine 🌈.
5.2. Countermeasures 💖
The primary countermeasure against attacks by untrusted network intermediaries is the security provided by the PT protocol. Any candidate PT protocols should be carefully examined to make sure all the threats described above are adequately addressed 🔍.
As noted above, compromise or erroneous operation of any trusted party is a serious matter with substantial security implications. That includes the Posture Broker Client, the Posture Broker Server, the Posture Transport Client, and the Posture Transport Server. These are all security-sensitive components, so they should be built and managed in accordance with best practices for security devices 🛡️. This is especially important for the NEA Server and its components, since compromise of this device would affect the security and availability of the entire network (similar to compromise of a AAA server) 🚨. Communications between the trusted parties must also be secured. For example, if the Posture Broker Server and the Posture Transport Server are separate components, their communications must be secured too 🔐.
Since the NEA Client may be a mobile device with little physical security (such as a laptop computer or even a public telephone), it should generally be assumed that some proportion of Access NEA Clients will be compromised and therefore hostile 😤. The NEA Server should be designed to be robust against hostile NEA Clients. Once a compromised NEA Client is detected, it can be treated the same way as an untrusted party and should pose no greater threat than any other untrusted party ✨.
Countermeasures against a compromised NEA Server (or a component of it, such as a Posture Broker Server or a Posture Transport Server) include prevention of compromise, detection of compromise, and mitigation of the effects of compromise. For prevention, the NEA Server and its components and dependencies should be implemented using secure implementation techniques (e.g., secure coding and minimization) and managed using secure practices (e.g., strong authentication and separation of duty) 🧱. For detection, the behavior of the NEA Server should be monitored (e.g., via logging, especially of remediation instructions, intrusion detection systems, and probes that impersonate a valid NEA Client and record NEA Server behavior), and any anomalies should be analyzed 🕵️♀️. For mitigation, NEA Clients should not blindly follow remediation instructions received from a trusted NEA Server. At least for patches and other dangerous actions, they should validate those actions (e.g., via user confirmation) before proceeding 🙅♀️. It should not be possible to configure a NEA Client to trust all NEA Servers without proper authentication and authorization. Absolutely not, periodt 💅
---
6. IANA Considerations 🌸
Four new IANA registries are defined by this specification: PB-TNC Message Types, PA Subtypes, PB-TNC Remediation Parameters Types, and PB-TNC Error Codes. This section explains how these registries work 📋.
All of these registries support IETF standard values and vendor-defined values. To explain how that works, we'll use the PB-TNC Message Type as an example, but the other three registries work the same way 🧚. Whenever a PB-TNC Message Type shows up on a network, it's always accompanied by an SMI Private Enterprise Number (PEN), also known as a vendor ID. If this vendor ID is zero, the accompanying PB-TNC Message Type is an IETF standard value listed in the IANA registry for PB-TNC Message Types, and its meaning is defined in the specification listed for that PB-TNC Message Type in that registry 💜. If the vendor ID is not zero, the meaning of the PB-TNC Message Type is defined by the vendor identified by the 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 PB-TNC Message Types used with their vendor ID, and to publish a specification for each of these values 🏷️.
This delegation of namespace is analogous to the technique used for OIDs. It can cause interoperability problems if vendors require support for particular vendor-specific values. However, this behavior is explicitly prohibited by this specification, which dictates that "Posture Broker Clients and Posture Broker Servers MUST NOT require support for particular vendor-specific PB-TNC message types and MUST interoperate with other parties despite any differences in the set of vendor-specific PB-TNC message types supported (although they MAY permit administrators to configure them to require support for specific PB-TNC message types)." Similar requirements are included for PA Subtypes, Remediation Parameters Types, and PB-TNC Error Codes 🫶.
6.1. Designated Expert Guidelines 🦋
For all four IANA registries defined by this specification, new values are added to the registry by Expert Review with Specification Required, using the Designated Expert process defined in RFC 5226 [5] 📝.
This section gives guidance to designated experts so they can make decisions using a philosophy that suits these registries 🧠.
These registries have plenty of values. In most cases, the IETF has approximately 2^32 values available to define, and each vendor has the same number of values for its own use. The only exception is the registry for PB-TNC Error Codes, where 2^16 values are available for the IETF and 2^16 values for each vendor. Because there are so many values available, designated experts should not be terribly concerned about running out 🌈.
Instead, designated experts should focus on the following requirements. All values in these IANA registries MUST be documented in a specification that is permanently and publicly available. IETF standard values MUST also be useful, not harmful to the Internet, and defined in a manner that is 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 standard value instead. However, it is beneficial to document existing practice 💅.
There are several ways to make sure a specification is permanently and publicly available. It may be published as an RFC. Alternatively, it may be published in another manner that makes it freely available to anyone. In that latter case, though, the vendor MUST supply a copy to the IANA and authorize the IANA to archive this copy and make it freely available to all if the document at some point stops being freely available to everyone through other channels 🔐🫶
6.2. Registry for PB-TNC Message Types ✨
okay so this registry is called "PB-TNC Message Types" 🎀 Every entry needs a human-readable name, an SMI Private Enterprise Number, a decimal integer from 0 to 2^32-2, and a reference to the spec that defines it. That spec must define what the message type means, plus the format and semantics of the PB-TNC Message Value field for messages that have the matching numeric value in the PB-TNC Message Type field and the matching Private Enterprise Number in the PB-TNC Vendor ID field. Main character energy for the details 💅
New entries get added through Expert Review with Specification Required, following the guidelines in section 6.1 🦋
These are the starter entries that this document defines. They're the first entries in the PB-TNC Message Types registry 🌸
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 0 PB-Experimental RFC 5793
0 1 PB-PA RFC 5793
0 2 PB-Assessment-Result RFC 5793
0 3 PB-Access-Recommendation RFC 5793
0 4 PB-Remediation-Parameters RFC 5793
0 5 PB-Error RFC 5793
0 6 PB-Language-Preference RFC 5793
0 7 PB-Reason-String RFC 5793
0 0xffffffff Reserved RFC 57936.3. Registry for PA Subtypes 🧚
This registry is called "PA Subtypes" 🍓 Each entry needs a human-readable name, an SMI Private Enterprise Number, a decimal integer from 0 to 2^32-2, and a reference to the spec for that PA subtype. The spec must define what the subtype means, plus the format and semantics of the PA Message Body field. That applies to PB-TNC messages with a PB-TNC Vendor ID of 0, a PB-TNC Message Type of PB-PA, the matching numeric value in the PA Subtype field, and the matching Private Enterprise Number in the PA Message Vendor ID field.
New entries come in through Expert Review with Specification Required, following the guidelines in section 6.1 🫶
This document doesn't define any starter entries for this one. So this registry should start out empty. Later RFCs, like PA-TNC, are the ones that will add entries here 🌈
6.4. Registry for PB-TNC Remediation Parameters Types 🔥
The name is "PB-TNC Remediation Parameters Types" 💜 Every entry needs a human-readable name, an SMI Private Enterprise Number, a decimal integer from 0 to 2^32-1, and a reference to the spec defining that remediation parameters type. The spec must define what the value means, plus the format and semantics of the Remediation Parameters field. That covers PB-TNC messages with a PB-TNC Vendor ID of 0, a PB-TNC Message Type of PB-Remediation-Parameters, the matching numeric value in the Remediation Parameters Type field, and the matching Private Enterprise Number in the Remediation Parameters Vendor ID field.
New entries get added through Expert Review with Specification Required, following the guidelines in section 6.1 ✨
Here are the starter entries this document defines. They're the first entries in the PB-TNC Remediation Parameters Types registry 🎀
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 1 Remediation-URI RFC 5793
0 2 Remediation-String RFC 57936.5. Registry for PB-TNC Error Codes 🙈
This one's called "PB-TNC Error Codes" 🌸 Each entry needs a human-readable name, an SMI Private Enterprise Number, a decimal integer from 0 to 2^16-1, and a reference to the spec where that error code is defined. The spec must define what the error code means, plus the format and semantics of the Error Parameters field. That's for PB-TNC messages with a PB-TNC Vendor ID of 0, a PB-TNC Message Type of PB-Error, the matching numeric value in the Error Code field, and the matching Private Enterprise Number in the Error Code Vendor ID field.
New entries are added by Expert Review with Specification Required, following the guidelines in section 6.1 🦋
These are the starter entries, defined right here in this document, so they're the first ones in the PB-TNC Error Codes registry 💖
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 0 Unexpected Batch Type RFC 5793
0 1 Invalid Parameter RFC 5793
0 2 Local Error RFC 5793
0 3 Unsupported Mandatory Message RFC 5793
0 4 Version Not Supported RFC 57937. Acknowledgments 🫶
Huge thanks to the Trusted Computing Group for contributing the initial text this document was built on 💜
The authors would also like to shout out the following people, who contributed to this document or its predecessors, or gave major input on it: Bernard Aboba, Amit Agarwal, Morteza Ansari, Diana Arroyo, Stuart Bailey, Boris Balacheff, Gene Chang, Roger Chickering, Scott Cochrane, Pasi Eronen, Aman Garg, Sandilya Garimella, Lauren Giroux, Mudit Goel, Charles Goldberg, Thomas Hardjono, Chris Hessing, Hidenobu Ito, John Jerrim, Meenakshi Kaushik, Greg Kazmierczak, Scott Kelly, Tom Kelnar, Bryan Kingsford, PJ Kirner, Houcheng Lee, Sung Lee, Lisa Lorenzin, Mahalingam Mani, Paul Mayfield, Michael McDaniels, Bipin Mistry, Rod Murchison, Barbara Nelson, Kazuaki Nimura, Ron Pon, Ivan Pulleyn, Alex Romanyuk, Chris Salter, Mauricio Sanchez, Paul Sangster, Dean Sheffield, Curtis Simonson, Jeff Six, Ned Smith, Michelle Sommerstad, Joseph Tardo, Lee Terrell, Chris Trytten, Brad Upson, Ram Vadali, Guha Prasad Venataraman, John Vollbrecht, Jun Wang, and Han Yin 👑✨
8. References 📚
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔥
[2] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. 🌈
[3] Phillips, A., Ed., and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009. 🦋
[4] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002. 🍓
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 🎀
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. 💜
8.2. Informative References
[7] Hanna, S., Hurst, R. and R. Sahita, "TNC IF-TNCCS: TLV Binding", Trusted Computing Group, February 2008. 🧚
[8] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, June 2008. 🌸
[9] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. 💖
[10] Sangster, P., and K. Narayan, "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5792, March 2010. ✨
Appendix A. Use Cases 🧚
A.1. Initial Client-Triggered Assessment 🎬
okay this scenario is an endpoint getting assessed while it's joining the network 🌐 The Posture Broker Client (PBC) kicks it off, and it collects patch info from both the Standard Operating System (OS) Posture Collector and a vendor-specific Patch Posture Collector (PC). Then the vendor-specific Patch Posture Validator (PV) and the Standard OS Posture Validator both assess it. When both come back compliant, the Posture Broker Server (PBS) returns a compliant System Assessment Decision. Iconic 👑
+--------+ +-------+ +---------+ +--------+ +-------+ +--------+
| Vndr. X| | Std. | | Std. | | Std. | | Std. || Vndr. X|
|Patch PC| | OS PC | | PBC | | PBS | | OS PV ||Patch PV|
+----+---+ +---+---+ +-----+---+ +---+----+ +---+----+| +---+---+The diagram above is copied exactly from the original, including its spacing and blank lines.
+--------+ +-------+ +---------+ +--------+ +-------+ +--------+Note: the lines above are reproduced verbatim from the original, and the diagram itself is long, so the full version follows in the next block.
| | N/W Join| | | |
| | ----->| | | |
| | Req Post. | | | |
| +<----------+ | | |
| | Req Post. | | | |
+<--------------------| | | |
|Vndr X Patch Posture | | | |
|-------------------->| | | |
| |OS Posture | | | |
| |---------->| | | |
| | | Posture | | |
| | | Report | | |
| | +-------->| | |
| | | | Verify | |
| | | | Posture | |
| | | |---------> |
| | | | | Verify |
| | | | | Posture |
| | | |------------------->|
| | | | OS Reslt | |
| | | |<---------| |
| | | | VndrX Patch Result |
| | | Assess |<-------------------|
| | | Result | |
| | <---------| | |
| | OS PRslt | | | |
| |<----------| | | |
| VndrX Patch PResult | | | |
|<--------------------| | | |A.1.1. Message Contents 💌
This part shows what's inside the key fields of each PA message in this use case 🎀 Where it's needed, extra commentary explains why certain fields hold the values they do. Heads up, lots of these flows happen between components on the same system, so no message contents get shown for those 🙈
A.1.1.1. N/W Join 🚪
This flow is the event that makes the PBC decide to start assessing the endpoint so it can get network access. It's just an event, though, not a message being sent 💅
A.1.1.2. Request Posture (Req Post.) 📨
This flow is the OS and Patch Posture Collectors getting invoked and asked to send particular posture attributes. Since this use case gets triggered locally, NEA doesn't specify what goes in this flow 🫶
A.1.1.3. Vendor X Patch Posture (VndrX Patch Posture) 🩹
This flow carries the PA message from the Vendor X Patch Posture Collector. The message content is described in the PA-TNC specification 🦋
A.1.1.4. OS Posture 💻
This flow carries the PA message from the OS Posture Collector. Again, the message content is described in the PA-TNC specification ✨
A.1.1.5. Posture Report 📬✨
okay so this flow is where the PB message gets packed up with the PA messages coming from the Patch and OS Posture Collectors 💅 the whole envelope looks like this:
PB Envelope {
HDR {
D bit=0 (Posture Broker Client is originator)
Batch Type=CDATA
Batch Length
}
PB Message 1 {
Vendor-id=0
Type =2 (PB-PA)
Length
Value = {
PA-Msg-vendor-id=0 (Standard)
PA-subtype=1 (OS)
OS Posture PA Message
}
}
PB Message 2 {
Vendor-id=0
Type =2 (PB-PA)
Length
Value = {
PA-Msg-vendor-id=1 (Vendor X)
PA-subtype=1 (Vendor X PA sub-type for patch management)
Vendor X Patch Posture PA Message
}
}
}A.1.1.6. Verify Posture 🔍
this one is giving "local only" energy 🙈 it shows an invocation of the OS and Patch Posture Validators asking them to verify the posture attributes they received. because it all happens locally inside the NEA server, NEA doesn't specify the message content. not its job here, bestie 💖
A.1.1.7. OS Posture Result (OS Reslt) 🎀
this flow carries the PA message (Posture Assessment Result) from the OS Posture Validator. the message content is described in the PA-TNC specification, so go check there for the deets 📖
A.1.1.8. Vendor X Patch Posture Result (VndrX Patch Result) 🦋
same energy as the one above! this flow carries the PA message (Posture Assessment Result) from the Vendor X Patch Posture Validator, and the message content is described in the PA-TNC specification 💜
A.1.1.9. Assessment Result (Assess Result) 👑
this is the big reveal, iykyk 😭 this flow has the PB message with the system assessment result that the Posture Broker Server computes, plus the PA messages from the Patch and OS Posture Validators:
PB Envelope {
HDR {
D bit=1 (Posture Broker Server is originator)
Batch Type=RESULT
Batch Length
}
PB Message 1 {
Vendor-id=0,
Type =3 (Access-Recommendation)
Length
Value = {
System-Evaluation-Result=0 (Compliant)
}
}
PB Message 2 {
Vendor-id=0,
Type=2 (PB-PA)
Length
Value = {
PA-Msg-vendor-id=0
PA-subtype=1 (OS)
OS Posture Result PA Message
}
}
PB Message 3 {
Vendor-id=0,
Type=2 (PB-PA)
Length
Value = {
PA-Msg-vendor-id=1 (Vendor X)
PA-subtype=1 (Vendor X PA sub-type for patch management)
Vendor X Patch Posture Result PA Message
}
}
}A.1.1.10. Posture Result (OS PRslt & Vndr X Post PResult) ⭐
these flows show an invocation of the OS and Vendor X Patch Posture Collectors to receive the posture assessment results. since this flow is triggered locally, NEA doesn't specify the contents here either 🫶
A.2. Server-Initiated Assessment with Remediation 🔥
this scenario is the NEA server starting the assessment of an endpoint. the Posture Broker Server triggers it and collects Anti-Virus attributes for two Anti-Virus components running on the endpoint 🛡️ Vendor X's anti-virus posture validator says the endpoint is compliant, but Vendor Y's says it's non-compliant 💀 so the Posture Broker Server returns a non-compliant System Assessment Decision. it also sends remediation instructions for the endpoint along with the response, ngl that's a lot of drama 😭
+--------+ +-------+ +---------+ +--------+ +-------+ +--------+
| Vndr Y | | Vndr X| | Std. | | Std. | | Vndr X| | Vndr Y |
| AV PC | | AV PC | | PBC | | PBS | | AV PV | | AV PV |
+----+---+ +---+---+ +-----+---+ +---+----+ +---+---+ +----+---+
| | | N/W Join| | |
| | | ----->| | |
| | | | Create | |
| | | |Post. Req | |
| | | |--------->| |
| | | |Create Posture Req |
| | | |----------+--------->|
| | | |Vndr Y AV Posture Req|
| | | |<---------+----------|
| | | |Vndr X AV | |
| | | |Post. Req | |
| | | Posture |<---------| |
| | | Request | | |
| | Vndr X AV |<--------| | |
| | Post. Req | | | |
| |<----------| | | |
| Vndr Y AV | | | |
| Posture Req | | | |
+<---------+-----------| | | |
| Vndr Y AV Posture | | | |
+----------+---------->| | | |
| | Vndr X AV | | | |
| | Posture | | | |
| |---------->| Posture | | |
| | |Response | | |
| | |-------->| | |
| | | | Verify | |
| | | | Posture | |
| | | |--------->| |
| | | | Verify Posture |
| | | |----------+--------->|
| | | |Vndr Y Posture Result|
| | | |<---------+----------|
| | | |Vndr X AV | |
| | | |Post Reslt| |
| | | Assess |<---------| |
| | | Result | | |
| | Vndr X AV |<--------| | |
| |Post Reslt |<--------| | |
| |<----------| | | |
| Vndr Y AV Post Reslt | | | |
+<---------+-----------| | | |
| | | | | |A.2.1. Message Contents 📝
this section shows the contents of the key fields in each PA message exchanged in this use case. when it's needed, there's extra commentary explaining why certain fields have the values they do 🤓 a lot of the flows are between components on the same system, so no message contents get shown for those ✨
A.2.1.1. N/W Join 🌐
this flow is the event that makes the PBS decide to start an assessment of the endpoint so it can get network access. it's merely an event and doesn't include a message being sent 🙃
A.2.1.2. Create Posture Request (Create Posture Req) 🧚
this flow shows the Vendor X and Vendor Y Anti-Virus posture validators invoked to create posture requests. because this use case is triggered locally, NEA doesn't specify the contents of this flow 🤷♀️
A.2.1.3. Vendor X Anti-Virus Posture Request (Vndr X AV Post. Req) 🍓
this flow carries the PA message (Posture Request) from the Vendor X Anti-Virus Posture Validator. the message content is described in the PA-TNC specification 📚
A.2.1.4. Vendor Y Anti-Virus Posture Request 🌸
this flow carries the PA message (Posture Request) from the Vendor Y Anti-Virus Posture Validator. the message content is described in the PA-TNC specification 📚
A.2.1.5. Posture Request 🦋
this flow has the PB message with the PA messages from the Vendor X and Vendor Y Anti-Virus Posture Validators:
PB Envelope {
HDR {
D bit=1 (Posture Broker Server is originator)
Batch Type=SDATA
Batch Length
}
PB Message 1 {
Vendor-id=0
Type =2 (PB-PA)
Length
Value = {
PA-Msg-vendor-id=1 (Vendor X)
PA-subtype=2 (Vendor X PA sub-type for Anti-Virus)
Vendor X AV Posture Request PA Message
}
}
PB Message 2 {
Vendor-id=0
Type =2 (PB-PA)
Length
Value = {
PA-Msg-vendor-id=2 (Vendor Y)
PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus)
Vendor Y AV Posture Request PA Message
}
}
}A.2.1.6. Process Posture Request (Vndr X AV Post Req & Vndr Y AV Posture Req) 💜
this flow shows the Vendor X and Vendor Y Anti-Virus Posture Collectors invoked to process the Posture Request and return the particular posture attributes requested. because this use case is triggered locally, NEA doesn't specify the contents of this flow 🫶
A.2.1.7. Vendor Y Anti-Virus Posture (Vndr Y AV Posture) 🌈
this flow carries the PA message (response to the Posture Request) from the Vendor Y Anti-Virus Posture Collector. the message content is described in the PA-TNC specification 📚
A.2.1.8. Vendor X Anti-Virus Posture (Vndr X AV Posture) 💖
this flow carries the PA message (response to the Posture Request) from the Vendor X Anti-Virus Posture Collector. the message content is described in the PA-TNC specification 📚
A.2.1.9. Posture Response 🎀
this flow has the PB message with the PA messages from the Vendor X and Vendor Y Anti-Virus Posture Collectors:
PB Envelope {
HDR {
D bit=0 (Posture Broker Client is originator)
Batch Type=CDATA
Batch Length
}
PB Message 1 {
Vendor-id=0
Type =2 (PB-PA)
Length
Value = {
PA-Msg-vendor-id=1 (Vendor X)
PA-subtype=2 (Vendor X PA sub-type for Anti-Virus)
Vendor X AV Posture PA Message
}
}
PB Message 2 {
Vendor-id=0
Type =2 (PB-PA)
Length
Value = {
PA-Msg-vendor-id=2 (Vendor Y)
PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus)
Vendor Y AV Posture PA Message
}
}
}A.2.1.10. Verify Posture 🔍
this flow shows the Vendor X and Vendor Y Anti-Virus Posture Validators invoked to verify the posture attributes they received. because this flow happens locally within the NEA server, NEA doesn't specify the message contents 🙈
A.2.1.11. Vendor Y Anti-Virus Posture Result (Vndr Y AV Post Result) 🔥
this flow carries the PA message (Posture Assessment Result) from the Vendor Y Anti-Virus Posture Validator. the message content is described in the PA-TNC specification 📚
A.2.1.12. Vendor X Anti-Virus Posture Result (Vndr Y AV Post Result) 🌟
this flow carries the PA message (Posture Assessment Result) from the Vendor X Anti-Virus Posture Validator. the message content is described in the PA-TNC specification 📚
A.2.1.13. Assessment Result (Assess Result) 🎀
okay so this flow is where the Posture Broker Server 🧚 puts together the system assessment result and sends it back. it also carries the PA messages from the Patch and OS Posture Validators, so it's giving full recap energy 💅
PB Envelope {
HDR {
D bit=1 (Posture Broker Server is originator)
Batch Type=RESULT
Batch Length
}
PB Message 1 {
Vendor-id=0,
Type=3 (Access-Recommendation)
Length
Value = {
PB-Assessment-Result=1 (Non-Compliant)
}
}
PB Message 2 {
Vendor-id=0,
Type=4 (Remediation-Parameters)
Length
Value = {
Remediation-Param-Vendor-ID=0
Remediation-Param-Type=1 (Remediation-URI)
Remediation-Param=''http://xyz''
}
}
PB Message 3 {
Vendor-id=0,
Type=4 (Remediation-Parameters)
Length
Value = {
Remediation-Param-Vendor-ID=0
Remediation-Param-Type=2 (Remediation-String)
Remediation-Param=''Try Step1, Step2,...''
}
}
PB Message 4 {
Vendor-id=0,
Type=2 (PB-PA)
Length
Value = {
PA-Msg-vendor-id=1 (Vendor X)
PA-subtype=2 (Vendor X PA sub-type for Anti-Virus)
Vendor X AV Posture Result PA Message
}
}
PB Message 5 {
Vendor-id=0,
Type=2 (PB-PA)
Length
Value = {
PA-Msg-vendor-id=2 (Vendor Y)
PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus)
Vendor Y AV Posture Result PA Message
}
}
}A.2.1.14. Posture Result (Vndr X AV Post Reslt & Vndr Y AV Post Reslt) ✨
these flows are the Vendor X and Vendor Y Anti-Virus Posture Collectors getting the posture assessment results. since this one gets triggered locally, NEA doesn't spell out what's in it 🙈
A.3. Client-Triggered Reassessment 🦋
this scenario is all about reassessing an endpoint because a software component just got switched on. so the endpoint has two VPN client components 👀 one from vendor X for the user's home network, and one from vendor Y for whatever network the endpoint is on right now. the assessment kicks off when the user tries to use the Vendor X VPN client, and that's a violation of the posture policy. the Posture Broker Client starts the whole posture assessment when it gets a heads-up from the Standard VPN Posture Collector that the VPN component's operational state changed.
quick note: the VPN Posture Collector supports standard attributes plus some vendor-defined ones from vendor X's and vendor Y's namespaces, but this use case doesn't use any vendor-defined attributes 💅 the assessment checks the standard VPN posture attributes through the Standard VPN Posture Validator, and the result comes back non-compliant 😭
this use case leans on the virtual Posture Collector concept from section 3.3 of the PA-TNC specification 🧚 here, the Posture Broker Client gives two Posture Collector IDs to one single Posture Collector (Standard VPN PC), and that collector sends two separate PA messages, one for the Vendor X VPN Client and one for the Vendor Y VPN Client. the Posture Broker Client uses those assigned IDs in the PB message it sends to the NEA Server. the NEA Server has no idea any of this is happening 🙈 it just treats the PB message like there are two VPN Posture Collectors on the NEA Client. iconic opacity tbh 🌈
+--------+ +-------+ +---------+ +--------+ +--------+ +--------+
|Vndr X | |Vndr Y | |Standard | |Standard| |Standard| |Standard|
|VPNClnt | |VPNClnt| | VPN PC | | PBC | | PBS | | VPN PV |
+----+---+ +---+---+ +-----+---+ +---+----+ +---+----+ +----+---+
Enble| | | | | |
---->| | | | | |
| VPN Status Change | | | |
|--------------------->| Posture | | |
| | | Change | | |
| | |-------->| | |
| | |Req. Post| | |
| | |<--------| | |
| |Ins/Rq Info| | | |
| |<----------| | | |
| Inspect/Request Info | | | |
|<---------+-----------|VPNX Post| | |
| | |-------->| | |
| | |VPNY Post| | |
| | |-------->| | |
| | | | Posture | |
| | | | Report | |
| | | |--------->| |
| | | | |Vrfy Post. |
| | | | |---------->|
| | | | |VPN PRslt |
| | | | Assess |<----------|
| | | | Result | |
| | | |<---------| |
| | |VPN PRslt| | |
| | |<--------| | |A.3.1. Message Contents 📝
this section shows what's inside the key fields of each PA message in this use case. where it's needed, there's extra commentary explaining why the fields have the values they do 💖 heads up, a lot of these flows happen between components on the same system, so no message contents get shown for those 🙈
A.3.1.1. Enable VPN Client (Enble) 🌸
this flow is the end user starting the VPN Client software from Vendor X. it's just an event, so no message gets sent ✨
A.3.1.2. Notify Status Change (VPN Status Change) 🔥
this flow is the Standard VPN Posture Collector noticing that the Vendor X VPN Client software is now active. it's just an event and doesn't include a message being sent 💅
A.3.1.3. Notify Posture Change (Posture Change) 🦋
this flow is the VPN Posture Collector telling the Standard Posture Broker Client that the VPN posture changed. again, an event only, no message sent 🧚
A.3.1.4. Request Posture (Req. Post) 🎀
this flow is the VPN Posture Collector asking for particular posture attributes to be sent. since this use case gets triggered locally, NEA doesn't specify what's in this flow 🙈
A.3.1.5. Inspect/Request Information (Ins/Rq Info) 💜
this flow is the Standard VPN Posture Collector collecting posture attributes from the Vendor X and Vendor Y VPN Client components. it's triggered locally, so NEA doesn't specify the message contents 💅
A.3.1.6. Vendor X VPN Posture (VPNX Post.) 🌈
this flow has the PA message from the VPN Posture Collector for the Vendor X VPN Client posture. the message content is described in the PA-TNC specification 🫶
A.3.1.7. Vendor Y VPN Posture (VPNY Post.) 🍓
this flow has the PA message from the VPN Posture Collector for the Vendor Y VPN Client posture. the message content is described in the PA-TNC specification ✨
A.3.1.8. Posture Report (Post. Rpt.) 📦
this flow has the PB message that carries the PA message from the VPN Posture Collector:
PB Envelope {
HDR {
D bit=0 (Posture Broker Client is originator)
Batch Type=CRETRY
Batch Length
}
PB Message 1 {
Vendor-id=0
Type =2 (PB-PA)
Length
Value = {
PA-Msg-vendor-id=0
PA-subtype=7 (VPN)
Posture-Collector-ID=1 //Virtual Posture Collector ID for
Vendor X VPN Client
Vendor X VPN Posture PA Message
}
}
PB Message 2 {
Vendor-id=0
Type =2 (PB-PA)
Length
Value = {
PA-Msg-vendor-id=0
PA-subtype=7 (VPN)
Posture-Collector-ID=2 //Virtual Posture Collector ID for
Vendor Y VPN Client
Vendor Y VPN Posture PA Message
}
}A.3.1.9. Verify Posture (Vrfy Post.) 🔍
this flow is the VPN Posture Validator being asked to verify the posture attributes it got. it happens locally inside the NEA server, so NEA doesn't specify the message contents 💖
A.3.1.10. VPN Posture Result (VPN PRslt) 🎉
this flow has the PA message (Posture Assessment Result) from the VPN Posture Validator. the message content is described in the PA-TNC specification ✨
A.3.1.11. Assessment Result (Assess Result) 👑
this flow has the PB message with the system assessment result the Posture Broker Server computed, plus the PA message from the VPN Posture Validator:
PB Envelope {
HDR {
D bit=1 (Posture Broker Server is originator)
Batch Type=RESULT
Batch Length
}
PB Message 1 {
Vendor-id=0,
Type =3 (Access-Recommendation)
Length
Value = {
PB-Assessment-Result=1 (Non-Compliant)
}
}
PB Message 2 {
Vendor-id=0,
Type=2 (PB-PA)
Length
Value = {
PA-Msg-vendor-id=0
PA-subtype=7 (VPN)
VPN Posture Result PA Message
}
}A.3.1.12. Posture Result (VPN PRslt) 🌷
this flow is the VPN Posture Collectors getting the posture assessment result. since it's triggered locally, NEA doesn't specify what's in this flow 🙈
Appendix B. Evaluation against NEA Requirements 💅
this section checks PB-TNC against the requirements in the NEA Requirements document. each subsection looks at one requirement from that doc. only the common requirements (C-1 through C-11) and the PB requirements (PB-1 through PB-6) get considered, since those are the only ones that apply to PB 🫶
B.1. Evaluation against Requirement C-1 💖
requirement C-1 says:
C-1 NEA protocols MUST support multiple round trips between the NEA
Client and NEA Server in a single assessment.PB-TNC meets this one, no notes 🙌 it allows an unlimited number of round trips between the NEA Client and NEA Server. unlimited, bestie 🌈
B.2. Evaluation against Requirement C-2 🦋
requirement C-2 says:
C-2 NEA protocols SHOULD provide a way for both the NEA Client and
the NEA Server to initiate a posture assessment or reassessment
as needed.PB-TNC meets this requirement too ✨ either the NEA Client or the NEA Server can start a posture assessment or reassessment.
there's one limitation though 🥺 if a NEA Server wants to start a reassessment after it has sent a RESULT batch, it must close the underlying transport session and start a new assessment. for half-duplex transports, that's unavoidable unless a constant exchange of messages is kept going, and that would be super wasteful 😭 for full-duplex transports, it would be possible to let the Posture Broker Server send an SRETRY batch even in the Decided state. if the NEA working group reaches consensus that this change should be made, it will be 💜
B.3. Evaluation against Requirement C-3 🔐
Okay so Requirement C-3 says:
C-3 NEA protocols including security capabilities MUST be capable
of protecting against active and passive attacks by
intermediaries and endpoints including prevention from replay-
based attacks.PB-TNC doesn't include any security capabilities 🙈. It depends on PT to supply a secure transport, and that covers all the necessary threats without adding an extra layer of security 🫶. Since this requirement only applies to NEA protocols that include security capabilities, PB-TNC meets this requirement ✨.
B.4. Evaluation against Requirement C-4 🦋
Requirement C-4 says:
C-4 The PA and PB protocols MUST be capable of operating over any
PT protocol. For example, the PB protocol must provide a
transport-independent interface allowing the PA protocol to
operate without change across a variety of network protocol
environments (e.g., EAP/802.1X, PANA, TLS, and IKE/IPsec).PB-TNC meets this requirement 💖. It can operate over any PT protocol that meets the requirements for PT stated in the NEA Requirements document. It also insulates the PA protocol from any specifics of the PT protocol, so from PA's point of view, all PT protocols are equivalent 🧚.
B.5. Evaluation against Requirement C-5 📚
Requirement C-5 says:
C-5 The selection process for NEA protocols MUST evaluate and
prefer the reuse of existing open standards that meet the
requirements before defining new ones. The goal of NEA is not
to create additional alternative protocols where acceptable
solutions already exist.Based on this requirement, PB-TNC should receive a strong preference 👑. PB-TNC is equivalent with IF-TNCCS 2.0, an open TCG specification. IF-TNCCS 2.0 is an extension of the existing IF-TNCCS 1.X protocols, which dozens of vendors and open source projects have already implemented. Literally iconic reuse energy 🌈.
B.6. Evaluation against Requirement C-6 🌸
Requirement C-6 says:
C-6 NEA protocols MUST be highly scalable; the protocols MUST
support many Posture Collectors on a large number of NEA
Clients to be assessed by numerous Posture Validators residing
on multiple NEA Servers.PB-TNC meets this requirement ⭐. It supports up to 2^16-1 Posture Collectors and an equal number of Posture Validators in a given PB-TNC session. It also supports an unlimited number of NEA Clients and NEA Servers 😭.
The scalability goes further too. PB-TNC supports an unlimited number of batches, and each batch can contain up to 2^32-1 octets and about 2^24 PA messages. Each PA message can contain up to 2^32-1 octets. Sending this much data in a NEA assessment isn't generally advisable 💀, but the point is that PB-TNC is highly scalable 💅.
B.7. Evaluation against Requirement C-7 🍓
Requirement C-7 says:
C-7 The protocols MUST support efficient transport of a large
number of attribute messages between the NEA Client and the NEA
Server.PB-TNC meets this requirement 🎀. Each PB-TNC batch can contain about 2^24 PA messages. Since PB-TNC supports an unlimited number of batches in a session, this number is effectively unlimited, except perhaps for limits from PT protocols, user patience, or other external factors. As for efficiency, PB-TNC adds only 24 octets of overhead per PA message. PA-TNC can include many attributes in a single PA message, so that overhead gets diluted even further 🫧.
B.8. Evaluation against Requirement C-8 🐢
Requirement C-8 says:
C-8 NEA protocols MUST operate efficiently over low bandwidth or
high latency links.PB-TNC meets this requirement 🙌. A minimal PB-TNC exchange can be as small as 72 octets and one round trip. Even if privacy policies or other factors require multiple round trips, PB-TNC generally adds only 8 octets per batch and 24 octets per PA message.
B.9. Evaluation against Requirement C-9 🌍
Requirement C-9 says:
C-9 For any strings intended for display to a user, the protocols
MUST support adapting these strings to the user's language
preferences.PB-TNC meets this requirement 🗣️. It defines a standard way for the NEA Client and NEA Server to send their language preferences to each other. It does this by leveraging the widely implemented Accept-Language format defined in RFC 3282 💖.
B.10. Evaluation against Requirement C-10 ✍️
Requirement C-10 says:
C-10 NEA protocols MUST support encoding of strings in UTF-8 format.PB-TNC meets this requirement 🌟. All strings in the PB-TNC protocol are encoded in UTF-8, which lets it support a wide range of languages efficiently 🌏.
B.11. Evaluation against Requirement C-11 🛜
Requirement C-11 says:
C-11 Due to the potentially different transport characteristics
provided by the underlying candidate PT protocols, the NEA
Client and NEA Server MUST be capable of becoming aware of and
adapting to the limitations of the available PT protocol. For
example, some PT protocol characteristics that might impact the
operation of PA and PB include restrictions on which end can
initiate a NEA connection, maximum data size in a message or
full assessment, upper bound on number of round trips, and
ordering (duplex) of messages exchanged. The selection process
for the PT protocols MUST consider the limitations the
candidate PT protocol would impose upon the PA and PB
protocols.PB-TNC meets this requirement 🫶. It's designed to be flexible enough to work with a variety of underlying PT protocols, including ones with limits on message or assessment size, number of round trips, and duplex. Local APIs can let Posture Collectors and Posture Validators discover when they're in a less constrained deployment, so they can use more verbose attributes 🦄. Similarly, Posture Collectors could choose not to send or use smaller attributes (including assertions from previous assessments) when they're facing a very constrained network connection 🐣.
B.12. Evaluation against Requirement PB-1 📬
Requirement PB-1 says:
PB-1 The PB protocol MUST be capable of carrying attributes from the
Posture Broker Server to the Posture Broker Client. This
enables the Posture Broker Client to learn the posture
assessment decision and if appropriate to aid in remediation
and notification of the endpoint owner.PB-TNC meets this requirement ✅. It can carry attributes from the Posture Broker Client to the Posture Broker Server and back, in an unlimited number of round trips. It also provides explicit attribute support for posture decisions and remediation aid notification 🎯.
B.13. Evaluation against Requirement PB-2 🙈
Requirement PB-2 says:
PB-2 The PB protocol MUST NOT interpret the contents of PA messages
being carried; i.e., the data it is carrying must be opaque to
it.PB-TNC meets this requirement 🧁. It doesn't parse or interpret PA messages in any way 🤐.
B.14. Evaluation against Requirement PB-3 🗺️
Requirement PB-3 says:
PB-3 The PB protocol MUST carry unique identifiers that are used by
the Posture Brokers to route (deliver) PA messages between
Posture Collectors and Posture Validators. Such message
routing should facilitate dynamic registration or
deregistration of Posture Collectors and Validators. For
example, a dynamically registered anti-virus Posture Validator
should be able to subscribe to receive messages from its
respective anti-virus Posture Collector on NEA Clients.PB-TNC meets this requirement 📮. It tags each PA message with a PA subtype that the Posture Brokers can use to deliver the PA messages to the proper Posture Collectors and Posture Validators. By tagging messages according to their content, PB-TNC lets Posture Collectors and Posture Validators be dynamically registered and deregistered, so each one still gets the proper data 🦋. PB-TNC also supports exclusive delivery, which lets messages be targeted at one particular Posture Collector or Posture Validator 🎯.
B.15. Evaluation against Requirement PB-4 🌊
Requirement PB-4 says:
PB-4 The PB protocol MUST be capable of supporting a half-duplex PT
protocol. However, this does not preclude PB from operating
full-duplex when running over a full-duplex PT.PB-TNC meets this requirement 🎉. To insulate PA from any differences between half-duplex and full-duplex PT protocols, PB-TNC always operates in a half-duplex mode, no matter what the PT protocol can do. In theory this could slow down assessments that need lots of round trips or bidirectional multimedia exchanges. In practice, though, it's not a problem, because endpoint assessments don't typically involve multimedia or a large number of round trips 💅.
B.16. Evaluation against Requirement PB-5 🔒
Requirement PB-5 says:
PB-5 The PB protocol MAY support authentication, integrity, and
confidentiality protection for the attribute messages it
carries between a Posture Broker Client and Posture Broker
Server. This provides security protection for a message dialog
of the groupings of attribute messages exchanged between the
Posture Broker Client and Posture Broker Server. Such
protection is orthogonal to PA protections (which are end to
end) and allows for simpler Posture Collector and Validators to
be implemented, and for consolidation of cryptographic
operations possibly improving scalability and manageability.PB-TNC does not address this optional requirement 🙃. It leaves security to PT (which is required to address it) and to PA (which SHOULD do so). There seems to be minimal benefit in adding a third layer of security to the NEA protocol stack, so we're not going there 💀. However, if the NEA working group decides that PB should include support for authentication, integrity protection, and confidentiality protection, then this could be added to PB in a similar manner to the way that the PA-TNC security is done 🛠️.
Lowkey the main takeaway here is that PB-TNC trusts PT and PA to handle security, and only adds a third layer if the working group asks for it 🔐.
B.17. Evaluation against Requirement PB-6 🧩
Requirement PB-6 says:
PB-6 The PB protocol MUST support grouping of attribute messages to
optimize transport of messages and minimize round trips.PB-TNC meets this requirement 🫰. Multiple attribute messages can be conveyed in a single PA message. In fact, that's how PA-TNC works ✨.
Authors' Addresses 🎀
Ravi Sahita
Intel Corporation
2200 Mission College Blvd.
Santa Clara, CA 95054 USA
EMail: Ravi.Sahita@intel.com
Steve Hanna
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, CA 94089 USA
EMail: shanna@juniper.net
Ryan Hurst
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052 USA
EMail: Ryan.Hurst@microsoft.com
Kaushik Narayan
Cisco Systems Inc.
10 West Tasman Drive
San Jose, CA 95134 USA
EMail: kaushik@cisco.com📦 where this page comes from
- ietf: rfc5793 2010-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms