RFC 5792
PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)
PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC) 🦋
Okay bestie, this is RFC 5792 💖. It's a Standards Track doc from March 2010, published under the IETF's ISSN 2070-1721. The authors are P. Sangster from Symantec Corporation and K. Narayan from Cisco Systems. The title block doesn't list anything it obsoletes or updates, so there's no drama there 🙈.
Abstract ✨
So this doc specifies PA-TNC, a Posture Attribute protocol that's identical to the Trusted Computing Group's IF-M 1.0 protocol 🫶. After that, it checks PA-TNC against the requirements in the NEA Requirements spec. Lowkey the whole vibe is "here's the protocol, now let's see if it passes the test" 💅.
Status of This Memo 🎀
This is an Internet Standards Track document 🌈. It's a product of the IETF, which means it represents the consensus of the IETF community. It got public review and was approved by the Internet Engineering Steering Group (IESG) 👑. If you want the deets on Internet Standards, check out Section 2 of RFC 5741.
Info about the current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc5792 💜.
Copyright Notice 💖
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved 🔥.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info (as of the publication date). Please actually read those, bestie, because they explain your rights and restrictions 📜. Any code components pulled out of this doc have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, same as that license says 🫠.
This doc might contain material from IETF Documents or IETF Contributions that were published or made public before November 10, 2008. Some of that copyright might belong to people who never gave the IETF Trust permission to let it be modified outside the IETF Standards Process 🙅♀️. So unless you get a proper license from those copyright holders, you can't modify this doc outside the IETF Standards Process, and you can't make derivative works outside it either. The exceptions are formatting it for RFC publication or translating it into languages other than English 🌸.
Table of Contents 📚
1. Introduction ....................................................4
1.1. Prerequisites ..............................................4
1.2. Message Diagram Conventions ................................4
1.3. Conventions Used in This Document ..........................4
2. Design Considerations ...........................................4
2.1. Standard Attribute Namespace for Interoperability ..........4
2.2. Vendor-Defined Namespace for Differentiation and Agility ...5
2.3. Use of TLV-Based Encoding for Efficiency ...................6
3. PA-TNC Message Protocol .........................................7
3.1. PA-TNC Messaging Model .....................................7
3.2. PA-TNC Relationship to PB-TNC ..............................8
3.3. PB-PA Posture Collector and Posture Validator
Identifiers ...............................................10
3.4. PA-TNC Messages in PB-TNC .................................10
3.5. IETF Standard PA Subtypes .................................11
3.6. PA-TNC Message Header Format ..............................12
4. PA-TNC Attributes ..............................................13
4.1. PA-TNC Attribute Header ..................................13
4.2. IETF Standard PA-TNC Attribute Types .....................17
4.2.1. Attribute Request ..................................18
4.2.2. Product Information ................................20
4.2.3. Numeric Version ....................................22
4.2.4. String Version .....................................24
4.2.5. Operational Status .................................26
4.2.6. Port Filter ........................................29
4.2.7. Installed Packages .................................31
4.2.8. PA-TNC Error .......................................34
4.2.9. Assessment Result ..................................41
4.2.10. Remediation Instructions ..........................42
4.2.11. Forwarding Enabled ................................45
4.2.12. Factory Default Password Enabled ..................47
4.3. Vendor-Defined Attributes ................................48
5. Security Considerations ........................................48
5.1. Trust Relationships .......................................48
5.1.1. Posture Collector ..................................49
5.1.2. Posture Validator ..................................49
5.1.3. Posture Broker Client, Posture Broker Server .......49
5.2. Security Threats ..........................................50
5.2.1. Attribute Theft ....................................50
5.2.2. Message Fabrication ................................51
5.2.3. Attribute Modification .............................51
5.2.4. Attribute Replay ...................................52
5.2.5. Attribute Insertion ................................52
5.2.6. Denial of Service ..................................53
6. Privacy Considerations .........................................53
7. IANA Considerations ............................................54
7.1. Designated Expert Guidelines ..............................55
7.2. PA Subtypes ...............................................56
7.3. Registry for PA-TNC Attribute Types .......................56
7.4. Registry for PA-TNC Error Codes ...........................57
7.5. Registry for PA-TNC Remediation Parameters Types ..........58
8. Acknowledgments ................................................58
9. References .....................................................59
9.1. Normative References ......................................59
9.2. Informative References ....................................59
Appendix A. Use Cases .............................................60
A.1. Initial Client-Triggered Assessment .......................60
A.2. Server-Initiated Assessment with Remediation ..............64
A.3. Client-Triggered Reassessment .............................71
Appendix B. Evaluation against NEA Requirements ...................77
B.1. Evaluation against Requirements C-1 .......................77
B.2. Evaluation against Requirements C-2 .......................77
B.3. Evaluation against Requirements C-3 .......................77
B.4. Evaluation against Requirements C-4 .......................78
B.5. Evaluation against Requirements C-5 .......................78
B.6. Evaluation against Requirements C-6 .......................78
B.7. Evaluation against Requirements C-7 .......................79
B.8. Evaluation against Requirements C-8 .......................79
B.9. Evaluation against Requirements C-9 .......................79
B.10. Evaluation against Requirements C-10 .....................80
B.11. Evaluation against Requirements C-11 .....................80
B.12. Evaluation against Requirements PA-1 .....................81
B.13. Evaluation against Requirements PA-2 .....................81
B.14. Evaluation against Requirements PA-3 .....................81
B.15. Evaluation against Requirements PA-4 .....................82
B.16. Evaluation against Requirements PA-5 .....................82
B.17. Evaluation against Requirements PA-6 .....................831. Introduction 🌸
So this doc specifies PA-TNC, a Posture Attribute (PA) Protocol that's identical to the Trusted Computing Group's IF-M 1.0 protocol [8]. Then it evaluates PA-TNC against the requirements from the Network Endpoint Assessment (NEA) Requirements specification [9]. Main character energy, literally 🧚.
1.1. Prerequisites
This doc doesn't define an architecture or reference model 🙅♀️. What it does do is define a protocol that works inside the reference model from the NEA Overview and Requirements specification. The reader is assumed to know that doc inside and out, and no TCG familiarity is assumed 🎀.
1.2. Message Diagram Conventions
This spec defines the syntax of PA-TNC messages with diagrams 📐. Each diagram shows the format and size of each field in bits. Implementations MUST send the bits in each diagram exactly as they're shown 🔥. You read the diagram top to bottom, then left to right within each line, and each line stands for a 32-bit quantity. Multi-byte fields that hold numeric values must be sent in network (big endian) byte order 💜.
Bit field values, like flags, are described by their bit position within the field. The positions are numbered from the most significant bit down to the least significant bit. So a 1-octet field with only bit 0 set has the value 0x80 🫶.
1.3. 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] 🍓.
2. Design Considerations 🧚
This section talks about some of the key design considerations for the PA protocol ✨.
2.1. Standard Attribute Namespace for Interoperability
Okay so PA needs two kinds of namespaces 💅: component types (AKA PA subtypes) and attributes. Each category needs well-known, interoperable names with defined syntax and semantics, and those names have to coexist with names for vendor-defined private extensions ✨. Each category also has to be easy to extend without endless coordination, while still avoiding naming conflicts 🫶.
PA-TNC and PB-TNC give you multiple orthogonal namespaces for each category that don't overlap, because each field comes with a Structure of Management Information (SMI) Private Enterprise Number (PEN) that says who defined the namespace it belongs to 🦋. This lets the IETF NEA WG define a set of standard component types and attribute types, while vendors can each make their own names outside the IETF standard namespace 🌸. Over time, vendor-defined names might get proposed for standardization and move into the IETF namespace 💜.
PB-TNC defines an IETF standard namespace (using vendor-id=0) for standard component types, like Operating System, Firewall, and Anti-Virus, using the PA Subtype field (see section 3.2) 💖. PA-TNC defines a set of standard attributes in section 4.2 that cover the most common capabilities (attributes) of these types of components across a bunch of vendor implementations 👑. The standard namespace means NEA deployments with both open source and vendor-provided NEA implementations can support a consistent set of policies across their environment, all based on these standard attributes 🌈. And the standard attributes work with a variety of endpoints (hosts, printers, mobile devices) running applications and operating systems (defined by the PA subtypes) from all sorts of vendors 🧚.
2.2. Vendor-Defined Namespace for Differentiation and Agility
Endpoints are a super dynamic place, bestie 😭. New features get deployed all the time, and attacks keep getting crafted against existing and new applications, like viruses, worms, malware, and spyware 💀. It's honestly hard to imagine the standard namespaces keeping up with all of that. Vendors usually stand out by moving fast to ship unique mechanisms for these threats, so being agile is their whole thing 🔥.
So PA-TNC and PB-TNC allow for creating vendor-defined namespace(s), where each one lets vendors use their own PA subtypes to identify non-standard applications or operating system variants, plus their own attributes describing new aspects of each type of component ✨. These vendor namespaces let NEA deployments write compliance policies that mix attributes from the IETF standard namespace with vendor-defined ones, possibly from several vendors, covering the different hardware and software components on the endpoints 🎀.
The way PA-TNC uses vendor-id to identify the namespace of each attribute means Posture Collectors can support some or all of the IETF standard attributes, plus optionally a set of vendor-defined attributes (potentially from more than one vendor-id namespace) 🦋. For example, an open source anti-virus Posture Collector could be written to support all of the IETF standard attributes used to describe a local anti-virus component, plus a subset of multiple anti-virus manufacturers' vendor-defined attributes. That collector could then interoperate with Posture Validators from multiple vendors 🌸. On the flip side, a simple Posture Collector could be written to ignore any vendor-defined attributes requested and only return the standard attributes it supports 🙈. If the vendor-provided Posture Validator's policy says that subset counts as compliant, those simple collectors can still run a successful assessment 💖.
2.3. Use of TLV-Based Encoding for Efficiency
PA-TNC went with a binary encoding using a type-length-value (TLV) structure 🤖. TLV was picked over a textual format like XML to make better use of the potentially constrained bandwidth between the NEA Client and NEA Server (see NEA Overview and Architecture [9]) 🍓. Efficiency was the main goal here, and two things were considered:
- Optimizing the bits-on-the-wire so NEA can meet its requirements for assessment over low bandwidth or high latency links (C-8), and so the Posture Transport (PT) protocol can run over existing network access protocols (PT-4, C-11) that are limited by packet size 📦.
- Optimizing CPU use on the endpoint, for low power endpoints like mobile devices 🔋.
Choosing TLV doesn't rule out XML-based attribute values inside the vendor namespaces or in future standard attributes 💅. It's totally conceivable that some vendors will use XML for extensibility within their own namespace, especially when the considerations above matter less for their technology 🌈. Attributes encoded in the vendor-defined namespace with an alternate encoding like XML will be opaque to NEA software that only supports standard attributes, and they'll mostly get processed by the vendor-defined components (collector/validator) 🫶.
3. PA-TNC Message Protocol ✨
This section is all about the PA-TNC message and its attributes 🦋. It covers the syntax and semantics for the PA-TNC message header, and the details of each attribute carried in the PA-TNC payload are specified in section 4.2 💖.
3.1. PA-TNC Messaging Model
PA-TNC messages get carried by the PB-TNC protocol [5] 🚚. PB-TNC gives you a multi-roundtrip reliable transport and end-to-end message delivery to subscribed (interested) parties, over a variety of underlying network protocols 🌸. PA-TNC doesn't know anything about those underlying PT protocols under PB-TNC, and honestly it doesn't need to 🙈.
The interested parties are Posture Collectors on the NEA Client and Posture Validators associated with the NEA Server, which have registered to receive messages about particular types of components (e.g., anti-virus) during an assessment 👑. The PA-TNC messaging protocol works synchronously within an assessment session, with Posture Collectors and Posture Validators taking turns sending one or more messages to each other 🔄. Each PA-TNC message can contain one or more attributes tied to the functional component identified in the component type (PA Subtype) of the Posture Broker (PB) protocol 🧚.
Posture Collectors may only send PA-TNC messages to Posture Validators, and vice versa. No Posture Collector-to-Posture Collector or Posture Validator-to-Posture Validator messaging is allowed to occur 🚫. Each Posture Collector or Posture Validator can send several PA-TNC messages in a row before saying it's done with its batch to the Posture Broker Client or Posture Broker Server, respectively 💅. As needed, the Posture Broker Client and Posture Broker Server will batch these messages before sending them over the network 📦.
PB-TNC uses a publish/subscribe model of message exchange 📣. That means at any given moment, zero or more subscribers for a particular type of message might be present on a Posture Broker Client or Posture Broker Server ✨. This is great, because one Posture Collector or Posture Validator can combine multiple functions (like anti-virus and personal firewall) by subscribing to both TNC standard component types 🎀. It also lets multiple Posture Collectors or Posture Validators support the same components, like two anti-virus Posture Validators that each manage their own anti-virus client software 🌈.
BUT (okay, it's not all sunshine 😭) this publish/subscribe model has some possible negative side effects. When a Posture Collector or Posture Validator first sends a PA-TNC message, it has no idea whether it'll get many, one, or zero PA-TNC messages back from the other side 🤷♀️. For lots of assessments that's fine, but sometimes you need a more direct channel binding between a particular Posture Collector and Posture Validator pair 💜. For example, a Posture Validator might want to send remediation instructions to one specific Posture Collector that it knows can fix a non-compliant component 🛠️. That's done with the exclusive delivery PB-TNC capability, which limits distribution of a message to a single Posture Collector by putting the target Posture Collector Identifier in the PB-PA header 🎯. For more on the PB-PA header, see section 4.5 of the PB-TNC specification 💖.
3.2. PA-TNC Relationship to PB-TNC ✨
okay so this section gives us a quick peek at what a PA-TNC message looks like when it's chilling inside a PB-TNC message 🦋 The double line (===) in the diagram is the border between PB-TNC and PA-TNC. The PA-TNC part gets delivered to every Posture Collector or Posture Validator that signed up for messages with a particular message type 💅 Also, PB-TNC can carry multiple PB-TNC and PA-TNC messages in a single PB-TNC batch, so it's a whole squad. See the PB-TNC specification [5] for more on what it can do.
One super important link between PA-TNC and PB-TNC is the PA message type (PA Message Vendor ID and PA Subtype). The Posture Broker Client and Posture Broker Server use it to route messages to the Posture Collectors and Posture Validators who care 🎀 The message type tells you which software component (the component type) the attributes inside the PA-TNC message are about. So Posture Collectors and Posture Validators built to assess a specific component can sign up to get messages about it and join in on that assessment 🧚 Each Posture Collector and Posture Validator MUST only send PA-TNC messages containing attributes that pertain to the software component defined in the message type of the message. This is how only the right Posture Collectors and Posture Validators, the ones who support that component type, get the attributes about it 🔥 If a PA-TNC message mixed attributes about different components but only had the message type for one of them, it would only be delivered to folks interested in that one component type, so everyone else would miss those attributes 💀
The message type is made of two fields: a PA Message Vendor ID and a PA Subtype. The PA Message Vendor ID tells you which vendor or other organization defined the message type. The PA Subtype tells you the message type more specifically, within the set of message types that vendor defined 🌸 This specification defines several IETF Standard PA Subtypes to be used with a PA Message Vendor ID of zero (0). In this spec, the PA Subtype field is used to show the type of component (e.g., firewall) that the message's attributes are about. So, for clarity, the PA subtype is called the "component type" in this specification 💜 Vendor-defined namespaces may use other semantics for the PA Subtype field, since that's outside the scope of this specification.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Message of type PB-PA-Message |
|(includes PA Message Vendor ID, PA Subtype, and other fields |
| used by Posture Broker Client and Posture Broker Server for |
| routing) |
===============================================================
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Message Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute |
| (e.g., Product Information) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute |
| (e.g., Operational Status) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1. Overview of a PB-TNC batch that contains a PA-TNC message
Let's say a Posture Broker Client sends a PB-TNC batch with a PA-TNC message whose message type says firewall component. The Posture Broker Server routes that message to the Posture Validators registered to assess firewalls 🛡️ Each of those Posture Validators gets its own copy of the PA-TNC message, including the PA-TNC header and the set of attributes. It's really important that every attribute in that PA-TNC message is about the firewall component, because only the Posture Collectors and Posture Validators into firewalls will get it 🙈
Now, if that same message had both firewall and operating system attributes inside a PA-TNC message with a component type of firewall, then any Posture Collector and Posture Validator registered for operating system messages would miss those attributes. The messages only go to the folks registered for firewall messages, so those OS attributes just vanish from their view 😭
3.3. PB-PA Posture Collector and Posture Validator Identifiers 🪪
The PB-PA header has a bunch of fields that matter when you're processing a received PA message 💖 The PA Vendor ID and Subtype are described in the PB-TNC specification and up in section 3.2. The PB-PA header also has a pair of fields that identify the Posture Collector and/or Posture Validator involved in the exchange. These fields are used for exclusive delivery of messages, as described in section 3.1, and as a way to correlate the attributes that get received 🔗
Correlation is needed when the sending Posture Collector reports posture for multiple implementations of one type of component during an assessment. That means the recipient Posture Validators need to know which attributes are describing the same implementation, so they don't mix things up 🌈
Here's an example: one Posture Collector might report attributes on two installed VPN implementations on the same endpoint. The individual attributes don't say which VPN product they're describing, so the recipient needs something else to match them up. So in this case, the VPN Posture Collector would need to get two Posture Collector Identifiers from the Posture Broker Client and consistently use one with each implementation during an assessment 🦋 The VPN Posture Collector groups all the attributes for a particular VPN implementation into a single PB-PA message, and sends it with the Posture Collector Identifier it picked for that implementation. That way the recipient can tell when attributes in later assessment messages describe that same implementation again 👑
3.4. PA-TNC Messages in PB-TNC 📦
Like we saw in section 3.2, a PA-TNC message is a PA-TNC header followed by a sequence of one or more attributes 🎀 The PA-TNC message header (covered in section 3.6) and the header for each PA-TNC attribute (specified in section 4.1) both use a fixed type-length-value (TLV) format. Each PA-TNC message MAY contain a mix of standards-based and vendor-defined attributes, and you can spot which is which from the type portion of the attribute header 🌸 All Posture Collectors and Posture Validators compliant with this specification MUST be capable of processing multiple attributes in a received PA-TNC message, no excuses 💅 A Posture Collector or Posture Validator that gets a PA-TNC message can use the attribute header's length field to skip any attributes it doesn't understand, unless the attribute is marked as mandatory to process. That's the length field doing its little hero moment ✨
3.5. IETF Standard PA Subtypes 🌟
This section defines several IETF Standard PA Subtypes. Each PA subtype defined here identifies a specific component relevant to the endpoint's posture 🍓 This is the glow-up trick: a small set of generic PA-TNC attributes (e.g., Product Information) can describe a huge number of different components (e.g., operating system, anti-virus, etc.). It also lets Posture Collectors and Posture Validators specialize in one component and only receive the PA-TNC messages about it 🧚
Value Integer Definition
----- ------- ----------
0 Testing Reserved for use in specification
examples, experimentation and
testing.
1 Operating System Operating system running on the
endpoint
2 Anti-Virus Host-based anti-virus software
3 Anti-Spyware Host-based anti-spyware software
4 Anti-Malware Host-based anti-malware (e.g., anti-
bot) software not included within
anti-virus or anti-spyware components
5 Firewall Host-based firewall
6 IDPS Host-based Intrusion Detection and/or
Prevention Software (IDPS)
7 VPN Host-based Virtual Private Network
(VPN) software
8 NEA Client NEA client softwareThese PA subtypes must be used in a PB-PA message with a PA Message Vendor ID of zero (0), which indicates an IETF standard type of component (as described in the PB-TNC specification [5]) 🩷 If these PA subtype values are used with a different PA Message Vendor ID, they have a completely different meaning, one that this specification does not define. Posture Collectors and Posture Validators MUST NOT require support for particular vendor-specific PA subtypes, and they MUST interoperate with other parties even if the set of vendor-specific PA subtypes each one supports is different 🫶 They MAY let administrators configure them to require support for specific PA subtypes, though, so the choice is there if you want it 🔥
3.6. PA-TNC Message Header Format ✨
okay so this bit is about the PA-TNC header 🎀 It's the thing that sits at the very front of every PA-TNC message, no exceptions. Every single PA-TNC message MUST start with one. It gives all the attributes in the payload their shared context 💅 The payload is just a sequence of assessment attributes, which we cover in section 4.2. It's giving organised.
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Version 🦋
This field tells you which format version the PA-TNC message is using. The whole point is that the version is easy for recipients to spot, so the header and payload can evolve later without anyone getting confused 🌸
Senders MUST set this field to 0x01 for every PA-TNC message that follows this spec ✨ If you're responding to a message with a version you support, you MUST use that same version number too, so nobody ends up with a version mismatch 🫶 And if a recipient gets a message with a version it doesn't support, it MUST reply with a Version Not Supported error. That error goes in a PA-TNC Error attribute, and it has to be the only PA-TNC attribute in a message with version number 1 💀
Implementations that speak more than one PA-TNC version SHOULD be able to switch which version they send, based on how earlier exchanges went with a particular peer Posture Collector or Posture Validator. Smart bestie behaviour 🧚
Reserved 🌈
This one is reserved for future use 🍓 Senders MUST set it to 0 when transmitting, and receivers ignore it when they get it. Hands off, basically 🙈
Message Identifier 💜
This field holds a value that uniquely identifies the message, so it can be told apart from every other message that a particular PA-TNC message sender has sent during the same assessment 👑 A response can include this value to show which message it's answering. PA-TNC error messages also carry it, so whoever gets the error can work out which of their messages triggered it. It's the receipt system, honestly iconic 🔥
PA-TNC message senders MUST NOT send the same message identifier more than once during an assessment. The values can be random or sequenced, as long as nothing repeats during that assessment's message exchange 🦋 Recipients aren't required to check for duplicates, so that part's on the sender 💅
4. PA-TNC Attributes 🎀
okay this section is the attribute section and it's where the real magic lives ✨ It sets up the standard attribute header that sits at the start of every attribute in a PA-TNC message 💖 Then it defines each of the IETF Standard PA-TNC Attributes. The last part talks about how vendor-defined PA-TNC attributes can be used inside a PA-TNC message. Vendor-defined attributes put the vendor's SMI Private Enterprise Number in the Attribute Type field, so the vendor is clearly identified 🌸
A PA-TNC message MUST contain a PA-TNC header (defined in section 3.6. followed by zero or more PA-TNC attributes. Every PA-TNC attribute MUST begin with a standard PA-TNC attribute header, as defined in section 4.1. The contents of attributes vary a LOT depending on their attribute type 🌈 Section 4.2 covers the IETF Standard PA-TNC Attributes, and section 4.3 talks about how vendor-specific PA-TNC attributes can be defined 🧚 Basically the header comes first, then the attributes, and every attribute starts with its own header 👑
4.1. PA-TNC Attribute Header
Okay so after the PA-TNC message header, you get a whole squad of attributes (zero or more, we love a flexible list 🎀). Every PA-TNC attribute MUST begin with the standard PA-TNC attribute header we're about to break down ✨. Each attribute in this spec is a TLV tuple, which has an attribute identifier made of the Vendor ID and Attribute Type (type), then the tuple's overall length, and finally the attribute's value. TLV was picked because it's super flexible and extensible, and other standards already use it 💅. Recipients check the attribute type to figure out the exact syntax and meaning of the value, and they use the length to skip right past anything they don't recognize 🦋 The length is also clutch when the value is variable-length 🫶
The TLV format doesn't have an explicit version number 🙈 so every attribute in one PA-TNC message MUST use the same TLV format. The PA-TNC message version number tells everyone what TLV format all the attributes in that message are using, so future changes to the format can be detected by recipients 🧚 Requiring the same format for every attribute also means a recipient that supports a given message version can at least parse every attribute header and use the length to skip the ones it doesn't know 💖 Last but not least, all attribute TLVs in one PA-TNC message MUST pertain to the same implementation of the component. This one matters when a single Posture Collector is reporting on several implementations of a component, because it has to send multiple PA-TNC messages, each one including only the attributes describing a single implementation. For more on how Posture Collectors handle multiple implementations, check section 3.3 📚
Every PA-TNC-compliant TLV attribute MUST use the following TLV format:
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-TNC Attribute Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Value (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Flags
This field is where the flags live, and they change how the attribute gets processed 🎀
Bit 0 (0x80) is the NOSKIP flag. Any Posture Collector or Posture Validator that receives an attribute with this flag set to 1 but doesn't support that attribute MUST NOT process any part of the PA-TNC message 🚫 and SHOULD respond with an Attribute Type Not Supported error in a PA-TNC error message 💀
Here's the tea: to avoid acting on some of the attributes only to later hit an unsupported one with NOSKIP set, recipients of a multi-attribute PA-TNC message might need to scan all of the attributes before acting on any of them 🔍
When the NOSKIP flag is set to 0, recipients SHOULD skip any unsupported attributes and keep going with the next one ✨
Bits 1-7 are reserved for future use 🧚 These bits MUST be set to 0 on transmission and ignored on reception.
PA-TNC Attribute Vendor ID
This field tells you who owns the namespace for the PA-TNC Attribute Type 🏷️ It does that by holding the 24-bit SMI Private Enterprise Number Vendor ID of the party who owns that Attribute Type namespace. IETF Standard PA-TNC Attribute Types MUST use zero (0) in this field 💜
Heads up, 0xffffff is reserved! Posture Collectors and Posture Validators MUST NOT send PA-TNC messages where the PA-TNC Attribute Vendor ID has this reserved value (0xffffff) 🙅♀️ If a Posture Collector or Posture Validator gets a message where the Vendor ID is 0xffffff, it SHOULD respond with an Invalid Parameter error code in a PA-TNC Error attribute 🚨
PA-TNC Attribute Type
This field defines the type of the attribute in the Attribute Value field 🦋 It's qualified by the PA-TNC Attribute Vendor ID, which means the same Attribute Type value (like 327) can mean something totally different depending on the Vendor ID. Posture Collectors and Posture Validators MUST NOT require support for particular vendor-specific PA-TNC Attribute Types 🫶 and MUST interoperate with other parties despite any differences in which vendor-specific types they support. (They MAY let admins configure them to require support for specific PA-TNC attribute types, though 🛠️)
If the PA-TNC Attribute Vendor ID is zero (0), then the PA-TNC Attribute Type field holds an IETF Standard PA-TNC Attribute Type, which is listed in the IANA registry 📋 IANA keeps the registry of PA-TNC Attribute Types, and new entries get added by Expert Review with Specification Required, following the guidelines in section 7. Section 4.2 of this specification defines the initial set of IETF Standard PA-TNC Attribute Types 🌸
Also, 0xffffffff is reserved! Posture Collectors and Posture Validators MUST NOT send PA-TNC messages where the PA-TNC Attribute Type has this reserved value (0xffffffff) 😭 If a Posture Collector or Posture Validator receives a message where the Attribute Type is 0xffffffff, it SHOULD respond with an Invalid Parameter error code in a PA-TNC Error attribute 💅
PA-TNC Attribute Length
This field holds the length in octets of the entire PA-TNC attribute, including the PA-TNC Attribute Header (that's the Flags, PA-TNC Attribute Vendor ID, PA-TNC Attribute Type, and PA-TNC Attribute Length fields) 📏 So this value MUST always be at least 12 🌈 Any Posture Collector or Posture Validator that gets a message with a PA-TNC Attribute Length less than 12 SHOULD respond with an Invalid Parameter PA-TNC error code 🙈 Similarly, if a Posture Collector or Posture Validator gets a PA-TNC message for an Attribute Type with a well-known Attribute Value length (like a fixed-length value) and the Attribute Length says something different, whether greater or less than expected, the recipient SHOULD respond with an Invalid Parameter PA-TNC error code 🚨
Implementations that don't support the specified PA-TNC Attribute Type can use this length to skip over that attribute and move on to the next one 🦋 Fun fact, though (okay, it's a limit 😅): while this field is 4 octets, the maximum usable attribute length is less than 2^32-1 because of limitations in the underlying protocol stack. Specifically, the PB-TNC TLV header's Batch Length field is also 32 bits long. That means the biggest batch PB-TNC can carry is 2^32-1, so the largest PA-TNC message carried by PB-TNC must be less than 2^32-1 - size of the PB-TNC header (see section 4.1 of PB-TNC for more details) 🧚
Attribute Value
This field changes depending on the type of attribute being expressed 🎨 The contents for each of the IETF Standard PA-TNC Attribute Types are defined in section 4.2 💖
4.2. IETF Standard PA-TNC Attribute Types
This section defines an initial set of IETF Standard PA-TNC Attribute Types 🌟 These Attribute Types MUST always be used with a PA-TNC Vendor ID of zero (0). If these PA-TNC Attribute Type values get used with a different PA-TNC Vendor ID, they mean something completely different, and that meaning isn't defined in this specification 🙅♀️
The table below briefly describes each attribute and the numeric value to use in the PA-TNC Attribute Type field of the PA-TNC Attribute Header 📋 Later subsections give the detailed specs for each PA-TNC Attribute Value 🫶
Number Integer Description
------ ------- -----------
0 Testing Reserved for use in
specification examples,
experimentation, and testing.
1 Attribute Request Contains a list of attribute
type values defining the
attributes desired from the
Posture Collectors.
2 Product Information Manufacturer and product
information for the component.
3 Numeric Version Numeric version of the
component.
4 String Version String version of the
component.
5 Operational Status Describes whether the component
is running on the endpoint.
6 Port Filter Lists the set of ports (e.g.,
TCP port 80 for HTTP) that are
allowed or blocked on the
endpoint.
7 Installed Packages List of software packages
installed on endpoint that
provide the requested
component.
8 PA-TNC Error PA-TNC message or attribute
processing error.
9 Assessment Result Result of the assessment
performed by a Posture
Validator.
10 Remediation Instructions Instructions for remediation
generated by a Posture
Validator.
11 Forwarding Enabled Indicates whether packet
forwarding has been enabled
between different interfaces on
the endpoint.
12 Factory Default Password Indicates whether the endpoint
Enabled has a factory default password
enabled.The following subsections talk about the usage, format, and semantics of the Attribute Value field for each IETF Standard PA-TNC Attribute Type 🎀 Let's gooo 🚀
4.2.1. Attribute Request ✨
okay so this is the attribute type where a Posture Validator gets to ask for specific stuff from the Posture Collectors 🎀 it's giving "send me your receipts" energy 💅
All Posture Collectors that implement any of the IETF Standard PA Subtypes defined in this specification SHOULD support receiving and processing this attribute type for at least those PA subtypes 🫶 this one is only a "should" though, because some deployments (see section A.1 🌸) have Posture Collectors that proactively send a set of attributes at the start of an assessment, based on local policy. Those ones don't need to handle Posture Validator requests at all 🙈 Posture Collectors that receive an Attribute Request but don't support it MUST respond with an Attribute Type Not Supported PA-TNC error code 😭 Posture Collectors that do handle it MAY send all, some, or none of the requested attributes, but MUST NOT send attributes that weren't requested (Error attributes are the exception 🚨). All Posture Validators that implement any of the IETF Standard PA Subtypes defined in this specification SHOULD support sending this attribute type for at least those PA subtypes 💜
Posture Validators MUST NOT include this attribute type in an Attribute Request attribute 💀 it would make zero sense to ask a Posture Collector to send another Attribute Request, periodt 🙃
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 1 🍓
Here's the layout for the Attribute Value field. The diagram shows two attribute types, but that's just for show ✨ a real Attribute Request can list anywhere from one to a huge pile of them (the only limit is the max message and length of the underlying PT protocol 🧚). Each Attribute Request MUST contain at least one attribute type 🌈 and since each requested attribute type is always 8 octets (the Vendor ID plus the Attribute Type, plus a 1-octet Reserved field), you can count how many were requested by taking the PA-TNC Attribute Length field, subtracting the PA-TNC Attribute Header, and dividing by 8 🧮 big brain moment 🧠 If the PA-TNC Attribute Length field is invalid, Posture Collectors SHOULD respond with an Invalid Parameter PA-TNC error code ✨
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 | PA-TNC Attribute Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | PA-TNC Attribute Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Reserved 🧊 Reserved for future use. This field MUST be set to 0 on transmission and ignored upon reception 🤍
PA-TNC Attribute Vendor ID 🏷️ This field holds the SMI Private Enterprise Number of the organization that controls the namespace for the PA-TNC Attribute Type that follows. It's what lets IETF Standard PA-TNC Attributes and vendor-defined ones coexist without collisions, which is so iconic 👑
Any IETF Standard PA-TNC Attribute Types defined in section 4.2 MUST use zero (0) in this field 💖 Vendor-defined attributes MUST use the SMI Private Enterprise Number of the organization that defined the attribute 🌷
PA-TNC Attribute Type 🎯 Together with the Vendor ID, this field tells you which specific attribute is being requested. Some IETF Standard PA-TNC Attribute Types MUST NOT be requested this way (for example, asking for a PA-TNC Error attribute 🙅♀️). The description of each of those types says so explicitly. If a Posture Collector or Posture Validator gets an Attribute Request containing one of these forbidden types, it SHOULD respond with an Invalid Parameter error in a PA-TNC error message 💅
4.2.2. Product Information 🦋
this is the attribute that tells everyone what product is doing the job ✨ it holds identifying info about the product that implements the component named in the PA Subtype field (see section 3.5). So if the PA Subtype is Anti-Virus, this attribute says which anti-virus product is living on the endpoint 🛡️💖
All Posture Collectors that implement any of the IETF Standard PA Subtypes defined in this specification MUST support sending this attribute type, at least for those PA subtypes 🫶 but whether a given Posture Collector actually sends it SHOULD still be governed by local privacy and security policies 🔐 (privacy matters, bestie 🥹). All Posture Validators that implement any of the IETF Standard PA Subtypes defined in this specification MUST support receiving this attribute type, at least for those PA subtypes 🌈 Posture Validators MUST NOT send this attribute type 🙅♀️
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 2 🎀 The PA-TNC Attribute Length field changes depending on how long the Product Name is, BUT it MUST be at least 17 💫 because that's the combined size of the fixed-length fields in the PA-TNC Attribute Header and the fixed-length fields in this attribute type. If the PA-TNC Attribute Length field is smaller than those fixed-length fields, implementations SHOULD respond with an Invalid Parameter PA-TNC error code 😭
This attribute carries both numeric and textual identifiers for the organization that made the product (the "product creator") and for the product itself 🧁 Numeric IDs are chef's kiss for automated processing 👑 because they're less ambiguous and more efficient. The catch is that numeric IDs only exist if the product creator actually assigned them, so a textual identifier is included too ✨ It's also a bit easier for humans to read, although the main job of this attribute is automated assessment, so that perk is pretty minimal 🙈
Here's the layout for the Attribute Value field 🧩
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Product Vendor ID | Product ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Product ID | Product Name (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Product Vendor ID 🏢 This is the SMI Private Enterprise Number for the product creator. If the product creator's SMI PEN is unknown, or the creator doesn't have one, the Product Vendor ID field MUST be set to 0 🫠 and the creator's identity SHOULD be included in the Product Name along with the product's name 🧾
Product ID 🔢 This field identifies the product using a numeric ID the product creator assigned. If that value is unknown, or the creator never assigned one, this field MUST be set to 0 💔 If the Product Vendor ID is 0, this field MUST be set to 0 too 🙃 In any case, the product's name SHOULD be included in the Product Name field 📛
⚠️ heads up, bestie: a particular Product ID value (like 635) can mean totally different things depending on the Product Vendor ID! Each Product Vendor ID defines its own separate space of Product ID values, so 635 from one vendor is not 635 from another 😱 Product creators are encouraged to publish lists of their Product ID values 📚
Product Name 📝 This variable-length field is a UTF-8 [2] string that names the product (e.g., "Symantec Norton AntiVirus(TM) 2008") in enough detail to tell it apart from the creator's other products 🔍 If the product creator is known but doesn't have a registered SMI Private Enterprise Number, the name SHOULD combine the creator's name and the full product name (e.g., "Ubuntu(R) IPtables" for the IPtables firewall in the Ubuntu distribution of Linux) 🐧✨ And if the creator's SMI PEN is already in the Product Vendor ID field, the creator's name may be omitted from this field 💅
To figure out how long the Product Name is, start with the PA-TNC Attribute Length field in the PA-TNC Attribute Header, then subtract the size of the fixed-length fields in that header (12) and the size of the fixed-length fields in this attribute (5) 🧮 If the PA-TNC Attribute Length field is less than the size of those fixed-length fields, implementations SHOULD respond with an Invalid Parameter PA-TNC error code 🥺
4.2.3. Numeric Version 🔢
okay so this attribute carries numeric version info for a product on the endpoint, specifically the one that the component in the PA Subtype field is about (see section 3.5) 💻. like if the PA Subtype is Operating System, this attribute holds the numeric version of the OS installed on the endpoint 🖥️. the version is tied to a specific product, so Posture Validators are expected to also have the matching Product Information attribute when they read it 🧠✨
time for the rules, bestie 📜. every Posture Collector that implements the IETF Standard PA Subtype for Operating System SHOULD support sending this attribute type, at least for the Operating System PA subtype 💜. other Posture Collectors MAY support sending it too 🌸. whether a specific collector actually sends it SHOULD still be governed by local privacy and security policies 🔐 (privacy is non-negotiable, babe 🫶).
on the receiving end, every Posture Validator that implements the IETF Standard PA Subtype for Operating System SHOULD support receiving this type, at least for that subtype 📥. other Posture Validators MAY support receiving it 🦋. if a Posture Validator doesn't support receiving this type, it SHOULD simply ignore attributes with this type 🙈. and Posture Validators MUST NOT send this attribute type 🚫 (never, ever, not me sending this 💅)
for the header fields, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 3 🎀. the PA-TNC Attribute Length field MUST be 28 📏. if the PA-TNC Attribute Length field is less than the size of these fixed-length fields, implementations SHOULD respond with an Invalid Parameter PA-TNC error code ⚠️
this attribute type has numeric values for the product version info, which lets Posture Validators do comparisons on the version 📊 that's the whole point, bestie 💖. some Posture Collectors might not be able to figure out some or all of this info for a product, which is fine 🤷♀️. it's especially useful for the operating system, since numeric version numbers are usually available for OSes 🍓
here's the layout of the Attribute Value field for this type, and the text after it describes each field 👀
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Major Version Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minor Version Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Build Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Pack Major | Service Pack Minor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Major Version Number 🔝
this field has the major version number for the product, if it applies 💅. if it's unused or unknown, this field SHOULD be set to 0 🫧
Minor Version Number 🌙
this field has the minor version number for the product, if it applies ✨. if it's unused or unknown, this field SHOULD be set to 0 🫧
Build Number 🛠️
this field has the build number for the product, if it applies 🧱. it can give you more granularity than the minor version number, since tons of builds can happen before an official release, and they can all share one major and minor number 🤯. if it's unused or unknown, this field SHOULD be set to 0 🫧
Service Pack Major 📦
this field has the major version number of the service pack for the product, if it applies 🎁. if it's unused or unknown, this field SHOULD be set to 0 🫧
Service Pack Minor 📦
this field has the minor version number of the service pack for the product, if it applies 🎀. if it's unused or unknown, this field SHOULD be set to 0 🫧
4.2.4. String Version 🧵
this attribute type has string version info for a product on the endpoint, for the component in the PA Subtype field (again, see section 3.5) 🌈. like if the PA Subtype is Firewall, this attribute holds the string version of a host-based firewall product on the endpoint, if there is one 🔥. the version info is tied to a specific product, so Posture Validators are expected to also have the matching Product Information attribute when they interpret it 👑
here's the rule book 📖. every Posture Collector that implements any of the IETF Standard PA Subtypes defined in this document MUST support sending this attribute type, at least for those PA subtypes 💪. other Posture Collectors MAY support sending it 🦋. whether a specific collector actually sends it SHOULD still be governed by local privacy and security policies 🔐. every Posture Validator that implements any of those IETF Standard PA Subtypes MUST support receiving this type, at least for those subtypes 📥. other Posture Validators MAY support receiving it 💜. and Posture Validators MUST NOT send this attribute type 🚫
header time 🎀. the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 4 🏷️. the PA-TNC Attribute Length field will vary, depending on the length of the Component Version Number, Internal Build Number, and Configuration Version Number fields 📐. but the PA-TNC Attribute Length field MUST be at least 15, because that's the length of the fixed-length fields in the PA-TNC Attribute Header plus the fixed-length fields in this attribute type 🧮. if the PA-TNC Attribute Length field is less than the size of these fixed-length fields, or doesn't match the length from adding up the fixed-length and variable-length fields, implementations SHOULD respond with an Invalid Parameter PA-TNC error code 😬
diagram time, and yes this one is a lot 🫠 the text after it breaks it all down 💖
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 Len | Product Version Number (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Build Num Len | Internal Build Number (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Config. Len | Configuration Version Number (Variable Length)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Version Len 🔢
this field has the number of octets in the Product Version Number field 🧮. if the product version number is unavailable or unknown, this field MUST be set to 0, and the Product Version Number field will be zero length (basically not there at all 👻)
Product Version Number 🏷️
this field is a UTF-8 string with the version of the component, like "1.12.23.114" 💫. this field MUST be sized to fit the version string, and it MUST NOT include extra octets for padding or NUL character termination 🧼
real talk, products use a wild mix of version formats 🌪️. some use letters, spaces, and punctuation, and some think version "1.21" is newer than "1.3" while others think it's older 🙃. so the syntax and semantics of this string are not defined 🤷♀️
Build Num Len 🔢
this field has the number of octets in the Internal Build Number field 🧮. for products where the internal build number is unavailable or unknown, this field MUST be set to 0, and the Internal Build Number field will be zero length (effectively not present 👻)
Internal Build Number 🛠️
this field is a UTF-8 string with the engineering build number of the product 🧱. this field MUST be sized to fit the build number string, and it MUST NOT include extra octets for padding or NUL character termination 🧼. the syntax and semantics of this string are not defined ✨
Config. Len ⚙️
this field has the number of octets in the Configuration Version Number field 🔢. if the configuration version number is unavailable or unknown, this field MUST be set to 0, and the Configuration Version Number field will be zero length (effectively not present 👻)
Configuration Version Number 🗂️
this field is a UTF-8 string with the version of the configuration the component uses 💜. this version SHOULD represent the overall configuration version, even if the component uses several configuration policy files or settings 📁. Posture Collectors MAY include multiple version numbers in this one string if a single version isn't practical 🧩. this field MUST be sized to fit the version string, and it MUST NOT include extra octets for padding or NUL character termination 🧼
again, products use lots of different version string formats 🌈. some use letters, whitespace, and punctuation, and some think "1.21" is newer than "1.3" while others think the opposite 🙃. some Posture Collectors might cram multiple configuration version numbers into this one string too 😅. so the syntax and semantics of this string are not defined 💅
4.2.5. Operational Status 💅
okay so this PA-TNC Attribute Type tells you the operational status of a product that can implement the component named in the PA Subtype field, as described in section 3.5 🦋. Like, if the PA Subtype is Anti-Spyware, this attribute holds info about a host-based anti-spyware product that might be running on the endpoint, or might not be installed at all 🙈
Posture Collectors that implement the IETF Standard PA Subtype for Operating System or VPN MAY support sending this attribute type for those PA subtypes 🎀. Posture Collectors that implement the other IETF Standard PA Subtypes in this spec SHOULD support sending it for those subtypes too. Other Posture Collectors MAY support sending it as well. Whether a given Posture Collector actually sends it SHOULD still be governed by local privacy and security policies, bestie, because privacy matters 🔒. On the receiving side, Posture Validators that implement the IETF Standard PA Subtype for Operating System or VPN MAY support receiving this attribute type, at least for those PA subtypes 💜. Posture Validators that implement the other IETF Standard PA Subtypes SHOULD support receiving it, at least for those subtypes. Other Posture Validators MAY support receiving it. A Posture Validator that doesn't support receiving this attribute type SHOULD simply ignore attributes with this type, no drama 🧚. And Posture Validators MUST NOT send this attribute type. Never. Not once. 🚫
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 5. The value in the PA-TNC Attribute Length field MUST be 36. If the PA-TNC Attribute Length field doesn't have this value, implementations SHOULD respond with an Invalid Parameter PA-TNC error code ⚠️.
Here's the layout of the Attribute Value field for this type. The text after the diagram explains each field 🍓.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Result | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Use |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Use (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Use (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Use (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Status
This field gives the operational status of the product. Here are the values currently defined for it ✨:
Value Description
----- -----------
0 Unknown or other
1 Not installed
2 Installed but not operational
3 OperationalIf a Posture Validator gets a value for this field that it doesn't recognize, it SHOULD treat that value as equivalent to the value 0 🤷♀️.
Result
This field contains the result of the last use of the product. Here are the values currently defined for it 💖:
Value Description
----- -----------
0 Unknown or other
1 Successful use with no errors detected
2 Successful use with one or more errors detected
3 Unsuccessful use (e.g., aborted)Posture Collectors SHOULD set this field to 0 if the Status field contains a value of 1 (Not installed) or 2 (Installed but not operational) 🙅♀️. If a Posture Validator gets a value for this field that it doesn't recognize, it SHOULD treat that value as equivalent to the value 0.
Reserved
This field is reserved for future use 🔮. It MUST be set to 0 on transmission and ignored upon reception.
Last Use
This field contains the date and time of the last use of the component ⏰. The Last Use date and time MUST be represented as an RFC 3339 [4] compliant ASCII string in Coordinated Universal Time (UTC), with the extra rules that the 't' delimiter and the 'z' suffix MUST be capitalized and fractional seconds (time-secfrac) MUST NOT be included. Main character energy, but make it strict 🎀.
This field follows the date-time ABNF production from section 5.6 of RFC 3339, with the restrictions above. Leap seconds are permitted, and Posture Validators MUST support them 🌈.
The last use string MUST NOT be NUL terminated or padded in any way. If the last use time is not known, not applicable, or can't be represented in this format, the Posture Collector MUST set this field to the value "0000-00-00T00:00:00Z", which keeps the field a fixed length 🧊. Note that this particular reserved value is not a valid RFC 3339 date and time, and it MUST NOT be used for any other purpose in this field 🚨.
This encoding makes a string that's easy to read, parse, and interpret, and it's giving clean vibes 😭. The format (more precisely defined in RFC 3339) is YYYY-MM-DDTHH:MM:SSZ, which gives you one and only one representation for each second in UTC time from year 0000 to year 9999 ⭐. For example, 9:05:00AM EST (GMT-0500) on January 19, 1995 can be represented as "1995-01-19T14:05:00Z". The length of this field is always 20 octets 💅.
4.2.6. Port Filter 🦋
okay this PA-TNC Attribute Type gives you the list of port numbers and their protocols (like TCP and UDP) that are currently blocked or allowed by a host-based firewall on the endpoint 🧱.
Posture Collectors that implement the IETF Standard PA Subtype for Firewall or VPN SHOULD support sending this attribute type for those PA subtypes 💜. Posture Collectors that implement the other IETF Standard PA Subtypes in this spec MUST NOT support sending it for those subtypes. Like, absolutely not 🙅♀️. Other Posture Collectors MAY support sending it, if it's appropriate for their PA subtype. Whether a given Posture Collector actually sends it SHOULD still be governed by local privacy and security policies 🔐. On the receiving end, Posture Validators that implement the IETF Standard PA Subtype for Firewall or VPN SHOULD support receiving this attribute type, at least for those PA subtypes 🫶. Posture Validators that implement the other IETF Standard PA Subtypes defined in this spec MUST NOT support receiving it for those subtypes. Other Posture Validators MAY support receiving it. A Posture Validator that doesn't support receiving this attribute type SHOULD simply ignore attributes with this type. And Posture Validators MUST NOT send this attribute type, periodt 🚫.
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 6 🔢.
Here's the layout of the Attribute Value field. The text after the diagram explains the fields 🍓. Heads up, this diagram shows two Protocol/Port Number pairs, but a Port Filter attribute can hold anywhere from one pair to a whole big pile of them (the only limit is the max message and length the underlying PT protocol supports) 🌸. Each Port Filter attribute MUST contain at least one Protocol/Port Number pair 🙌. Since a Protocol/Port Number pair (with the Reserved field and B flag) is always 4 octets, you can work out how many pairs there are by taking the PA-TNC Attribute Length, subtracting the octets in the PA-TNC Attribute Header, and dividing by 4 🧮. If the PA-TNC Attribute Length field is invalid, Posture Validators SHOULD respond with an Invalid Parameter PA-TNC error code 🚩.
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 |B| Protocol | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |B| Protocol | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Reserved
This field is reserved for future use 🔮. It MUST be set to 0 on transmission and ignored upon reception.
B Flag (Blocked or Allowed Port)
This single-bit field tells you whether the following port is blocked or allowed 🚧. This bit MUST be set to 1 if the protocol and port combination is blocked. Otherwise, this field MUST be set to 0. This field exists so the port filtering policy can be reported in a shorter way. For example, if all ports are blocked except a few, the Posture Collector can just list the few that are allowed 🧠.
Posture Collectors MUST NOT provide a mixed list of blocked and non-blocked ports for a particular protocol 🙃. To be more precise, a Posture Collector MUST NOT include two Protocol/Port Number pairs in a single Port Filter attribute where the protocol number is the same but the B flag is different. Also, Posture Collectors MUST NOT list the same Protocol and Port Number combination twice in a Port List attribute ❌.
Posture Collectors MAY list all blocked ports for one protocol and all allowed ports for a different protocol in a single Port List attribute, using the B flag to show whether each entry is blocked 🎨. For example, a Posture Collector might list all the blocked TCP ports but only list the allowed UDP ports. However, it MUST NOT list some blocked TCP ports and some other allowed TCP ports 💀.
Protocol
This field contains the transport protocol number (e.g., tcp is 6) being blocked or allowed 🔌. The values used here are the same ones used in the IPv4 Protocol and IPv6 Next Header fields. IANA already maintains the Assigned Internet Protocol Numbers registry of these values for use in this field 📒.
Port Number
This field contains the port number (for the transport protocol, e.g., tcp) being blocked or allowed 🎀. The values here are specific to the protocol named in the Protocol field. IANA maintains registries for well-known and user-requested TCP and UDP port numbers for use in this field 🌈.
4.2.7. Installed Packages 📦✨
okay so this attribute type is giving inventory list energy 💅 It carries a list of the installed packages that make up a product on the endpoint that implements the component named in the PA Subtype field (see section 3.5). That lets a Posture Validator check which packages are installed for a given product and which versions they are 🫶
Posture Collectors that implement any of the IETF Standard PA Subtypes defined in this document SHOULD support sending this attribute type for those PA subtypes. Other Posture Collectors MAY support sending it if it makes sense for their PA subtype 🌸 Whether a particular Posture Collector actually sends it SHOULD still be governed by local privacy and security policies, so privacy comes first, bestie 🔐 Posture Validators that implement any of the IETF Standard PA Subtypes defined in this document SHOULD support receiving this attribute type, at least for those PA subtypes. Other Posture Validators MAY support receiving it too. A Posture Validator that does not support receiving it SHOULD simply ignore attributes with this type 🙈 Posture Validators MUST NOT send this attribute type. no exceptions, no cap 💀
This attribute can be seriously long, especially for the Operating System PA subtype 😭 That can cause problems, especially over 802.1X and other limited transport protocols. So Posture Collectors SHOULD NOT send this attribute unless they are specifically asked to with the Attribute Request attribute or are otherwise configured to do so. Also, Posture Validators SHOULD NOT request this attribute unless the transport protocol in use can handle the big amount of data that might come back 🧚
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 7. The PA-TNC Attribute Length field changes depending on how many packages there are and how long the Package Name and Package Version Number fields are 🦋 But the PA-TNC Attribute Length field MUST be at least 16, because that's the size of the fixed-length fields in the PA-TNC Attribute Header plus the fixed-length fields in this attribute type. If the PA-TNC Attribute Length field is smaller than those fixed-length fields, or it doesn't match the total length of the fixed-length and variable-length fields, implementations SHOULD respond with an Invalid Parameter PA-TNC error code. yikes 😬
The diagram below shows the format and contents of the Attribute Value field for this attribute type. The text after it describes the fields. Note that the diagram only shows one package. The real number of package descriptions is in the Package Count field, which can be zero or a big number (up to 65535, if the underlying PT protocol can handle that many) 🍓 If that's not enough, specialized patch management software should be employed that can simply report compliance with a pre-established patch policy 🎀
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 | Package Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pkg Name Len | Package Name (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Len | Package Version Number (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Reserved
This field is reserved for future use 🔮 It MUST be set to 0 on transmission and ignored upon reception.
Package Count
This is an unsigned 16-bit integer that tells you how many packages are listed in this attribute. For each package counted, the attribute includes a Pkg Name Len, Package Name, Version Len, and Package Version Number field 💖
Pkg Name Len
This is an unsigned 8-bit integer for the length of the Package Name field, in octets. It can be zero if a Package Name isn't available 🙈
Package Name
This field has the name of the package associated with the product. It's a UTF-8 encoded character string, and its octet length is given by the Pkg Name Len field. It MUST NOT include extra octets for padding or NUL character termination 🚫 The syntax and semantics of this name aren't specified in this document, since they can vary across products and/or operating systems. Posture Collectors MAY list two packages with the same name in a single Installed Packages attribute. What that means isn't defined here 🤷♀️
Version Len
This is an unsigned 8-bit integer for the length of the Package Version Number field, in octets. It can be zero if a Package Version Number isn't available ✨
Package Version Number
This field has the version string for the package named in the previous Package Name field. It's a UTF-8 encoded character string, and its octet length is given by the Version Len field. It MUST NOT include extra octets for padding or NUL character termination. The syntax and semantics of this version string aren't specified in this document, since they can vary across products and/or operating systems 🌈 Posture Collectors MAY list two packages with the same Package Version Number (and even the same Package Name and Package Version Number) in a single Installed Packages attribute. What that means isn't defined here either 🦄
4.2.8. PA-TNC Error 🚨
This attribute type carries an error code plus extra info about an error involving PA-TNC 💅
All Posture Collectors and Posture Validators that implement any of the IETF Standard PA Subtypes defined in this specification MUST support sending and receiving this attribute type, at least for those PA subtypes. this one is non-negotiable bestie 🫶
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 8. The PA-TNC Attribute Length field changes with the length of the Error Information field 🎀 But the PA-TNC Attribute Length field MUST be at least 20, because that's the size of the fixed-length fields in the PA-TNC Attribute Header plus the fixed-length fields in this attribute type.
A PA-TNC error code SHOULD be sent with the same PA Message Vendor ID and PA Subtype that the offending PA-TNC message used, so the error goes back to whoever sent that message 📬 Other measures (like setting PB-TNC's EXCL flag and the Posture Collector Identifier or Posture Validator Identifier fields) SHOULD also be taken to try to make sure only the sender of the offending message gets the error 🔒
When a PA-TNC error code is received, the recipient MUST NOT respond with a PA-TNC error code, because that could create an infinite loop of errors 🔁💀 Instead, the recipient MAY log the error, change its behavior to try to avoid the error (avoiding loops or long strings of errors), ignore the error, terminate the assessment, or take other action as appropriate, as long as that's consistent with the requirements of this specification.
Posture Validators MUST NOT include this attribute type in an Attribute Request attribute. It doesn't make sense for a Posture Validator to ask a Posture Collector to send a PA-TNC Error attribute 🙃
The diagram below shows the format and contents of the Attribute Value field for this attribute type. The text after it describes 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | PA-TNC Error Code Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Information (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Reserved
This field is reserved for future use. It MUST be set to 0 on transmission and ignored upon reception.
PA-TNC Error Code Vendor ID
This field has the SMI Private Enterprise Number for the organization that defined the PA-TNC Error Code used in this attribute. For IETF Standard PA-TNC Error Code values, this field MUST be set to zero (0) 🏷️
PA-TNC Error Code
This field has the PA-TNC Error Code being reported in this attribute. Heads up 👀 a particular PA-TNC Error Code value can mean completely different things depending on the PA-TNC Error Code Vendor ID, because each Vendor ID defines its own space of error code values. Posture Collectors and Posture Validators MUST NOT require support for particular vendor-specific PA-TNC Error Codes, and they MUST interoperate with other parties despite differences in the set of vendor-specific PA-TNC Error Codes they support (although they MAY let administrators configure them to require support for specific PA-TNC Error Codes) 🤝
When the PA-TNC Error Code Vendor ID is set to zero (0), the PA-TNC Error Code is an IETF Standard PA-TNC Error Code. IANA maintains a registry of PA-TNC Error Codes. Entries in this registry are added by Expert Review with Specification Required, following the guidelines in section 7 📋
The table below lists the IETF Standard PA-TNC Error Codes defined in this specification:
Integer Description
------- -----------
0 Reserved
1 Invalid Parameter
2 Version Not Supported
3 Attribute Type Not SupportedThe next few subsections of this document give detailed definitions of these error codes 🌸
Error Information
This field gives extra context for the error. What's in it depends on the PA-TNC Error Code Vendor ID and PA-TNC Error Code. So whenever a PA-TNC Error Code is defined, the format of this field for that code must also be defined. The definitions of the IETF Standard PA-TNC Error Codes on the next few pages are good examples of how that's done 💜
The recipient can work out the length of this field from the PA-TNC Attribute Length field by subtracting the length of the fixed-length fields in the PA-TNC Attribute Header and the fixed-length fields in this attribute.
4.2.8.1. Invalid Parameter Error Code ✨
okay so the Invalid Parameter error code is an IETF Standard PA-TNC Error Code (value 1) 🎀. it basically says "hey, the sender of this error found an invalid value in a PA-TNC message that the recipient sent during the current assessment" 💅.
for this one, the Error Information field carries the first 8 octets of the PA-TNC message that had the bad parameter, plus an offset that tells you where the bad parameter sits inside that message 🔍.
here's the diagram for the Error Information field. the fields get explained right after it 🦋
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 | Copy of Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Version 🌸
This field MUST contain an exact copy of the Version field in the PA-TNC Message Header of the PA-TNC message that caused this error. no wiggle room bestie 🙈
Copy of Reserved 🌈
This field MUST contain an exact copy of the Reserved field in the PA-TNC Message Header of the PA-TNC message that caused this error.
Message Identifier 🍓
This field MUST contain an exact copy of the Message Identifier field in the PA-TNC Message Header of the PA-TNC message that caused this error.
Offset 🧚
This field MUST contain an octet offset from the start of the PA-TNC Message Header of the PA-TNC message that caused this error to the start of the value that caused this error. like, for example, if the very first PA-TNC attribute had an invalid PA-TNC Attribute Length (say, 0), this value would be 16 💖
4.2.8.2. Version Not Supported Error Code 🦋
the Version Not Supported error code is an IETF Standard PA-TNC Error Code (value 2) ✨. it means the sender doesn't support the PA-TNC version number in the PA-TNC Message Header of a message the recipient sent during the current assessment 🫶.
this one's giving a little more info. the Error Information field holds the first 8 octets of the PA-TNC message with the unsupported version, plus Max Version and Min Version fields that show which PA-TNC version numbers the sender of the error does support 👑.
the sender MUST support every PA-TNC version from Min Version up to Max Version, inclusive (so the Min Version and the Max Version are both included) 💜. when it's possible, recipients of this error code SHOULD send future messages to the Posture Collector or Posture Validator that originated this error with a PA-TNC version number inside that stated range 🌈.
any party sending the Version Not Supported error code MUST include it as the only PA-TNC attribute in a PA-TNC message with version number 1 💅. and all parties that send PA-TNC messages MUST be able to properly process a message like that, even if they can't handle anything else in PA-TNC version 1 🙈. this is what makes sure a PA-TNC version exchange can still go through, no matter which versions each party implements 🫶.
here's the Error Information diagram 🎀
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 | Copy of Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Version | Min Version | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Version 🌸
This field MUST contain an exact copy of the Version field in the PA-TNC Message Header of the PA-TNC message that caused this error.
Copy of Reserved 🌈
This field MUST contain an exact copy of the Reserved field in the PA-TNC Message Header of the PA-TNC message that caused this error.
Message Identifier 🍓
This field MUST contain an exact copy of the Message Identifier field in the PA-TNC Message Header of the PA-TNC message that caused this error.
Max Version 👑
This field MUST contain the maximum PA-TNC version supported by the sender of this error code.
Min Version 💜
This field MUST contain the minimum PA-TNC version supported by the sender of this error code.
Reserved 🧚
Reserved for future use. This field MUST be set to 0 on transmission and ignored upon reception.
4.2.8.3. Attribute Type Not Supported Error Code 💅
the Attribute Type Not Supported error code is an IETF Standard PA-TNC Error Code (value 3) 🦋. it tells you the sender doesn't support the PA-TNC Attribute Type that was in the Error Information field 🌸. that attribute type came in a PA-TNC message the recipient sent during the current assessment ✨.
for this one, the Error Information field has the first 8 octets of the PA-TNC message with the unsupported attribute type, and a copy of the attribute type that caused the problem 🎀.
diagram time, bestie 🔥
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 | Copy of Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | PA-TNC Attribute Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA-TNC Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Version 🌸
This field MUST contain an exact copy of the Version field in the PA-TNC Message Header of the PA-TNC message that caused this error.
Copy of Reserved 🌈
This field MUST contain an exact copy of the Reserved field in the PA-TNC Message Header of the PA-TNC message that caused this error.
Message Identifier 🍓
This field MUST contain an exact copy of the Message Identifier field in the PA-TNC Message Header of the PA-TNC message that caused this error.
Flags 🧚
This field MUST contain an exact copy of the Flags field in the PA-TNC Attribute Header of the PA-TNC attribute that caused this error.
PA-TNC Attribute Vendor ID 💖
This field MUST contain an exact copy of the PA-TNC Attribute Vendor ID field in the PA-TNC Attribute Header of the PA-TNC attribute that caused this error.
PA-TNC Attribute Type 🫶
This field MUST contain an exact copy of the PA-TNC Attribute Type field in the PA-TNC Attribute Header of the PA-TNC attribute that caused this error.
4.2.9. Assessment Result 👑
okay this attribute carries the final assessment result from a particular Posture Validator 💜. it's useful for information, like when an endpoint is compliant 🌈. it can also say "nope, not compliant," where specific actions are needed to get the endpoint back in line with the network's policies 🔥. those actions could be defined in other PA-TNC attributes, like Remediation Instructions sent to the Posture Collector 🦋.
all Posture Collectors that support an IETF Standard PA Subtype defined in this spec SHOULD support receiving and processing the Assessment Result attribute ✨. all Posture Validators that implement an IETF Standard PA Subtype defined here SHOULD support sending it 💅.
for this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0), and the PA-TNC Attribute Type field MUST be set to 9 🎀.
here's the Attribute Value diagram 💖
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 Validator assessed the endpoint component to
be compliant with policy.
1 Posture Validator assessed the endpoint component to
be non-compliant with policy but the difference from
compliant was minor.
2 Posture Validator assessed the endpoint component to
be non-compliant with policy and the assessed
difference was very significant.
3 Posture Validator was unable to determine policy
compliance of an endpoint component due to an error.
4 Posture Validator was unable to determine whether the
assessed endpoint component was compliant with policy
based on the attributes provided by the Posture
Collector.4.2.10. Remediation Instructions ✨
Okay bestie, this is the attribute the Posture Validator uses to send the Posture Collector the instructions for fixing a component so the endpoint passes the assessment policies 🛠️💖. Sometimes one fix needs more than one of these, like a URI and a human-readable message, and that's totally allowed 🫶. It can carry either an IETF standard instruction or a vendor-specific one 🌈.
Posture Collectors that implement an IETF Standard PA Subtype from this spec SHOULD support receiving and processing this attribute 🎀. Posture Validators that implement an IETF Standard PA Subtype from this spec SHOULD support sending it 💅. Anyone supporting other non-IETF standard components MAY support it too ✨.
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 10 🦋.
Here's the layout of the Attribute Value field. The text after the diagram explains each piece 👑.
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)
The Reserved bits MUST be set to 0 on transmission and ignored on reception 🌸.
Remediation Parameters Vendor ID (24 bits)
This field uses the SMI Private Enterprise Number (PEN) to identify a vendor 🏢. Any organization can get its own unique PEN from IANA, the Internet Assigned Numbers Authority 🧚. The Remediation Parameters Vendor ID is what makes the Remediation Parameters Type field work per vendor, so every vendor gets 2^32 separate Remediation Parameters Types to play with 🍓. Remediation Parameters Types that the IETF standardizes always go with the value zero (0) in this field 💜.
Remediation Parameters Type (32 bits)
This field tells you which kind of remediation instruction is sitting in the Remediation Parameters field 🔥. IANA keeps a registry of PA-TNC Remediation Parameters Types, and new entries get added by Expert Review with Specification Required, following the guidelines in section 7 📋. The IETF Standard ones defined in this spec are listed in the table below, and they show up later in this section 👀.
New vendor-specific remediation instructions can be made by adding new Remediation Parameters Types (the ones used with a non-zero Remediation Parameters vendor ID) without needing IETF or IANA involvement 🌈. Posture Collectors and Posture Validators MUST NOT require support for particular vendor-specific PA-TNC Remediation Parameters Types, and they MUST interoperate with other parties even if the vendor-specific sets they support are different 🫶. They MAY let admins configure them to require support for specific PA-TNC remediation parameter types though 🙈.
Here's the table of IETF Standard PA-TNC Remediation Parameters Type values from this spec 💖:
Integer Description
------- -----------
0 Reserved
1 Remediation URI
2 Remediation StringThe next couple of subsections give the full details for the contents of the Remediation Parameters field for each type 🎀.
Remediation Parameters (variable length)
This field holds the actual remediation instructions for the Posture Collector ✨.
4.2.10.1. Remediation URI Parameters Type
The Remediation URI Parameters Type is an IETF Standard Remediation Parameters Type (value 1). It means the Posture Validator is sending a URI that points to instructions for fixing the endpoint 🔗🦋.
This is the layout of the Remediation Parameters field when it carries a Remediation URI parameter. The text after the diagram describes 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 URI (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Remediation URI
The Remediation URI field MUST contain a URI, as described in RFC 3986 [7] 🌐. This URI SHOULD contain instructions to update a particular component so that it might result in the component being compliant with the policies in future assessments 📈. Posture Collectors should validate that the URI and instructions come from a trustworthy source so they don't get tricked into doing damaging stuff (see security considerations) 😭.
🚨 Bestie, this one is serious: check that the URI and instructions come from a trustworthy source before you act on them! Otherwise you could get tricked into doing something damaging 💀.
4.2.10.2. Remediation String Parameters Type
The Remediation String Parameters Type is an IETF Standard Remediation Parameters Type (value 2). It means the Posture Validator is sending a human-readable string with instructions for fixing the endpoint 📝💜.
This is the layout of the Remediation Parameters field when it carries a Remediation String parameter. The text after the diagram describes the fields here 🌸.
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
This is the length of the Remediation String field, in octets 📏.
Remediation String
The Remediation String field MUST contain a UTF-8 encoded string 🔤. It holds human-readable remediation instructions that MAY be shown to the user by the Posture Collector 👀. NUL termination MUST NOT be included 🙅♀️. If a Posture Collector gets a Remediation String that does have a NUL termination, it SHOULD send an Invalid Parameter error code ⚠️.
Lang Code Len (Remediation String Language Code Length)
This is the length of the Remediation String Language Code field, in octets 🌍.
Remediation String Lang Code
This field holds a US-ASCII string made of a well-formed RFC 4646 [6] language tag, saying which language(s) the Remediation String uses 🗣️. A zero-length string MAY be sent here (basically leaving the field out) to say the language code for the remediation string isn't known 🤷♀️.
4.2.11. Forwarding Enabled
This PA-TNC attribute says whether the endpoint is forwarding traffic between interfaces 🚦. Endpoints that forward traffic between networks on multiple network interfaces can be seen as non-compliant (and a security risk) in some enterprise deployments 🙈. Picture this: an endpoint with two connected interfaces lets traffic from a public network interface get forwarded out through another interface that's carrying a VPN session into a protected enterprise network 😱. Right now this attribute is mostly meant for reporting the posture of the operating system component, but it could be useful for other components in the future 🧚.
Posture Collectors that implement the IETF Standard PA Subtype for Operating System SHOULD support sending the Forwarding Enabled attribute 💻. Posture Collectors that don't implement the Operating System PA Subtype from this spec SHOULD NOT send Forwarding Enabled unless it makes sense for their PA Subtype 🙅♀️. Whether a particular Posture Collector actually sends it SHOULD still be governed by local privacy and security policies 🔐. Posture Validators that implement the IETF Standard PA Subtype for Operating System SHOULD support receiving Forwarding Enabled 📥. Posture Validators supporting other components MAY support receiving it if it fits their PA Subtype 🌈. A Posture Validator that doesn't support receiving it SHOULD simply ignore attributes with this type 😌. Posture Validators MUST NOT send this attribute type 🚫.
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 11 🎀.
Here's the layout of the Attribute Value field for this attribute 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding Enabled |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Forwarding Enabled
This 32-bit field MUST contain one of the following values; 🔢
Value Description
----- -----------
0 Disabled - Endpoint is not forwarding traffic.
1 Enabled - Endpoint is forwarding traffic.
2 Unknown - Unable to determine whether endpoint is
forwarding traffic4.2.12. Factory Default Password Enabled 🔑
okay bestie, this attribute tells you whether the endpoint has a factory default password turned on 🔐 Some endpoints ship with a built-in static password that gives privileged access. If nobody changes or disables it before the endpoint is reachable on the network, it's honestly so easy to break into 😭💀
Posture Collectors that implement the IETF Standard PA Subtype for Operating System SHOULD support sending the Factory Default Password Enabled attribute. Posture Collectors that implement the other IETF Standard PA Subtypes defined in this specification SHOULD NOT support sending this attribute type for those PA subtypes. Other Posture Collectors MAY support sending this attribute type if it makes sense for their PA subtype. Whether a particular Posture Collector actually sends it SHOULD still be governed by local privacy and security policies 🧚
Posture Validators that implement the IETF Standard PA Subtype for Operating System SHOULD support receiving the Factory Default Password Enabled attribute. Other Posture Validators MAY support receiving this attribute type. A Posture Validator that doesn't support receiving it SHOULD simply ignore attributes with this type. Posture Validators MUST NOT send this attribute type 🙅♀️
For this attribute type, the PA-TNC Attribute Vendor ID field MUST be set to zero (0) and the PA-TNC Attribute Type field MUST be set to 12 🎀
Here's the layout of the Attribute Value field for this type. The text right after the diagram walks through 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Factory Default Password Enabled |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Factory Default Password Enabled 🌸
This 32-bit field MUST contain one of the following values; 💜
Value Description
----- -----------
0 Endpoint does not have factory default password enabled.
1 Endpoint has a factory default password enabled.4.3. Vendor-Defined Attributes 🌈
This section is all about vendor-defined attributes in PA-TNC. The protocol was built so vendors can use their own attributes in place of a standard one when needed. Sometimes even the standard attributes have room for vendor-specific info inside them. The idea is that once a particular vendor-defined attribute gets really popular, a standard version of it could be added later so everyone can interoperate 🍓
This specification doesn't define any vendor-defined attributes. What it does do is show how they can be used with PA-TNC without causing namespace collisions or misinterpretations ✨ To keep things from colliding, PA-TNC uses SMI Private Enterprise Numbers as vendor IDs, which give each vendor its own namespace for important fields in a PA-TNC message. For example, to keep attribute types unique while still allowing vendor extensions, a vendor-defined attribute type includes the vendor's unique vendor ID (which marks the namespace), followed by the attribute type. IETF Standard PA-TNC Attribute Types use a vendor ID of zero (0) 💅
SMI Private Enterprise Numbers give every vendor its own identifier space. IANA keeps a registry of them, and any organization can get one for free. That includes non-profits, government bodies, and so on, and thousands of organizations already have one 🏳️🌈 In this document, SMI Private Enterprise Numbers are called "vendor IDs" 🫶
5. Security Considerations 🔥
okay this section is the serious part, so pay attention 👀 It covers the major kinds of security threats that matter for the PA-TNC message protocol. Down the road, more attribute types could be defined to help exchange security capabilities, keys, and security-protected attributes, if use cases come along that need those protections 🔐
5.1. Trust Relationships 🤝
To figure out where security countermeasures are needed, we first have to look at the trust relationships the TNC architecture expects between the processing elements of PA-TNC. The subsections below cover the trust properties of each part of the NEA reference model that's directly involved in processing PA-TNC 🧠
5.1.1. Posture Collector 📋
Posture Validators trust the Posture Collectors to:
- Collect valid information about the component type that goes with the Posture Collector
- Report collected information in line with local security and privacy policies
- Accurately report information about the type of component for the PA-TNC message
- Not act maliciously toward the Posture Broker Server and Posture Validators, including attacks such as denial of service
5.1.2. Posture Validator 🛡️
Posture Collectors trust the Posture Validators to:
- Only request the information needed to assess the endpoint's security state
- Make assessment decisions based on deployer-defined policies
- Discard collected information in line with data retention and privacy policies
- Not act maliciously toward the Posture Broker Server and Posture Collectors, including attacks such as denial of service
- Not send malicious remediation instructions that fail to fix the problem or that cause damage to the endpoint
5.1.3. Posture Broker Client, Posture Broker Server 🚚
The Posture Collector and Posture Validator trust the Posture Broker Client and Posture Broker Server to:
- Provide a reliable transport for PA-TNC messages
- Deliver messages for a particular PA Subtype only to the Posture Collectors and Posture Validators that registered for them
- Not disclose any provided attributes to unauthorized parties
- Not act maliciously by dropping messages, duplicating messages, or flooding Posture Collectors and Posture Validators with unnecessary messages
- Not observe, fabricate, or alter the contents of a PA-TNC message
- Properly place Posture Collector and Posture Validator identifiers into the PB-TNC protocol, deliver those identifiers to Posture Collectors and Posture Validators as needed, and manage exclusive delivery to a particular Posture Collector or Posture Validator when requested
- Properly expose authentication information from PT security so Posture Collectors and Posture Validators can use the peer's identity information to make policy decisions safely
5.2. Security Threats 😈
Beyond the trust relationships assumed in Section 5.1, the PA-TNC protocol faces a number of potential security attacks that could require countermeasures.
In general, PA-TNC relies on the underlying PT protocol's security to protect messages from attack while they travel over the network. Once a message is sitting on the Posture Broker Client or Posture Broker Server, the posture brokers are trusted to deliver it properly and safely to the right Posture Collectors and Posture Validators 🫧
5.2.1. Attribute Theft 🕵️♀️
When PA-TNC messages are sent over unprotected network links, or across local software stacks that aren't trusted, an intermediary can steal their contents. That theft could mean information gets recorded for later use or analysis by the adversary. Attributes an eavesdropper sees could reveal weaknesses in the endpoint's security, or system fingerprinting info that makes it easier to launch attacks that are more likely to succeed against the endpoint. The eavesdropper might also learn about endpoint or network policies that, alone or combined, count as sensitive (for example, certain endpoints are missing patches, or particular sub-networks have more lenient policies) 👀
PA-TNC attributes aren't meant to carry privacy-sensitive information, but if some end up in a message, an adversary who gets hold of them could use them for financial gain 💸 That's why PT needs to provide strong confidentiality protection, so eavesdroppers can't read the message while it's being sent between the Posture Transport Client and the Posture Transport Server.
5.2.2. Message Fabrication 🎭
Attackers on the network, or already inside the NEA system, could introduce fabricated PA-TNC messages to trick an assessment or cause a denial of service. For example, an adversary could try to send falsified remediation instructions through the Remediation URI support, hoping the Posture Collector will automatically follow them. Posture Collectors need to make sure any requests to take actions on the endpoint (such as remediation instructions) that they get from Posture Validators are authentic and trustworthy, using the strong authentication and integrity protections PT offers. Posture Collectors should not blindly follow remediation instructions received from a trusted NEA Server. At least for patches and other potentially dangerous actions, Posture Collectors should validate those actions (for example, through user confirmation) before going ahead 🙈
This kind of attack could happen if an active attacker runs a man-in-the-middle (MitM) attack by proxying PA-TNC messages and swaps out the ones they don't want for ones that make future attacks on the endpoint easier. Imagine PT security isn't in use and the Posture Broker Server proxies all assessment traffic to a remote Posture Broker Server. The proxy could eavesdrop on and replace assessment results attributes, tricking the endpoint into thinking it passed an assessment when it actually didn't and still needs remediation 😱
The Posture Collector has no way to verify that attributes were actually created by an authentic Posture Validator, so it can't detect a falsified attribute or message. That's why it's so important for PT to provide strong authentication and integrity protection 🔒💖
5.2.3. Attribute Modification ✨
okay so this attack lets an active attacker who can intercept a message change a PA-TNC message attribute to whatever value they want, which makes it way easier to compromise an endpoint 😈 The real problem is that if recipients can't tell whether a message has the same content it had when it was sent, active attackers can quietly tamper with the attribute exchange 🫣
For example, an attacker might want to change the firewall component's version string attribute so it hides that the firewall is running an old, vulnerable version 🙈 They'd swap the version string sent by the firewall Posture Collector for the current version number. The Posture Validator's assessment passes, but the endpoint is still vulnerable to attack 💀 It gets worse, too. An attacker could cause widespread denial of service by changing a bunch of assessments' version string attributes to an old value, so they keep failing even after a successful remediation 😭 Once the Posture Validator sees that lower value, it keeps believing the endpoint runs old, potentially vulnerable versions of the firewall that don't meet network compliance policy, so the endpoint isn't allowed to join the network. Using a PT protocol with strong integrity protection and authentication is essential as a countermeasure to these attacks, bestie 🫶
5.2.4. Attribute Replay
next up: replay attacks, and they're kind of sneaky 🦋 The PA-TNC attribute exchange isn't protected, and one of the gaps is that there's no strong binding between the attributes sent during an assessment and the specific endpoint they came from. Without that binding, an attacker could record the attributes from an assessment of a compliant endpoint and replay them later, so a non-compliant endpoint can suddenly get into the network or a protected resource 🥴
This attack could be pulled off by a network MitM that can eavesdrop on and proxy message exchanges, or by local rogue agents running on the endpoints. Assessments that don't have some form of freshness exchange are open to replays of old assessment data, even when that data no longer reflects the endpoint's current state 😬 So the fix is a PT protocol with strong integrity protection and authentication that also includes a freshness exchange. That's a necessary countermeasure to these attacks, no cap 🔐
5.2.5. Attribute Insertion
this one is kind of like attribute modification, except now the attacker is adding stuff instead of changing it ✨ An adversary who wants to slip one or more attributes or PA-TNC messages into a valid assessment might be able to do it without the recipient noticing. For example, an attacker could stick attributes at the front of a PA-TNC message so the assessment passes even for a non-compliant endpoint, especially if they know the recipient ignores repeated attributes within a message 👀
It's also a problem the other way around. If a Posture Collector or Posture Validator always threw an error when it saw unexpected attributes, an attacker could cause failures and denial of service just by adding attributes or messages to an exchange 💅 A PT protocol with strong authentication and integrity protection could stop the adversary from inserting attributes into the assessment, so that's the move 💖
5.2.6. Denial of Service
the denial-of-service situations here are a whole vibe 🌪️ There are lots of ways someone can mess with the PA-TNC message exchange if it's left unprotected from untrusted parties on the communication path between the Posture Collector and the Posture Validator. Normally the PT exchange is bidirectionally authenticated, which helps stop a MitM on the network from becoming an active proxy. But transparent message routing gateways can still sit on the path and change the integrity of the message exchange unless adequate integrity protection is provided 🙄
If a MitM or other entity on the network can send messages to the Posture Broker Client or Posture Broker Server that look like part of an assessment, those messages could confuse the Posture Collector and Posture Validator, or make them do unnecessary work or take incorrect action 😵💫 Several example denial-of-service situations are described in sections 5.2.3 and 5.2.5. There are plenty more, too, including flooding messages to the Posture Collector or Posture Validator, sending very large messages packed with lots of attributes, and repeatedly asking for resource-intensive operations 🔥
6. Privacy Considerations 🌸
okay this protocol is all about controlled disclosure of security-relevant information about an endpoint 🎀 The whole point is to enable an assessment of whether the endpoint is complying with network policy. It gives Posture Validators and the Posture Broker Server visibility into the state of the endpoint's protective mechanisms, so they can check whether the endpoint is up to date and has the best chance of holding up against malware threats 🛡️ The catch is that more visibility into an endpoint means a higher chance that privacy-sensitive information gets exposed without the user's consent, and that's something to keep in mind 🫣
the protocol does let the Posture Validator ask for specific information about the endpoint, but it isn't open-ended. The Posture Validator is bounded to querying only specific information (attributes) about specific security features (component types) on the endpoint 🔒 Every PA-TNC message is explicitly about one component from the list in section 3.5. That list covers security-related aspects of the endpoint that affect how well it can resist attacks, which is why they matter during an assessment 💜 Discretionary components that users rely on to create or view content aren't on the list, since those are much more likely to hold privacy-sensitive information 🙈
PA-TNC messages also carry a set of attributes that describe the particular component. Each attribute holds generic information, like product information or versions, so it's unlikely to include anything user-specific or identifying 🧚 Pairing a limited set of security-related components with non-user-specific attributes really lowers the risk of exposing privacy-sensitive info 🍓 Vendors who define their own component types and/or attributes within their namespace are encouraged to set up similar constraints, so everyone's on the same page 💖
even with standard attribute information tied to specific components, people might want to share less with different networks. A user might be happy to share more when connecting to or being reassessed by their employer's network than they'd want to share with the local coffee shop wifi ☕ These situations don't change the protocol itself, but they do suggest that Posture Collector implementations should consider supporting a privacy filter. That way the user and/or system owner can restrict access to certain attributes based on the target network 🌈
The underlying PT protocol authenticates the network's Posture Broker Server at the start of an assessment, so the Posture Collector can know who it's talking to, and per-network privacy filtering is possible 🔐 Network owners should make available a list of the attributes they need to perform an assessment, along with any privacy policy they enforce when handling the data 📋 Users who want a more restricted privacy filter on the endpoint might not be able to pass an assessment, which means they may not get access to the requested network or resource. That's the trade-off, bestie 😅
7. IANA Considerations 📚
this section sets up three new IANA registries: PA-TNC Attribute Types, PA-TNC Error Codes, and PA-TNC Remediation Parameters Types 🎀 It also explains how those registries work, and it defines several new PA Subtypes for use with PA-TNC ✨
all of the registries defined in this document support both IETF standard values and vendor-defined values. to explain how that works, we'll use the PA-TNC Attribute Type as the example, but the other three registries work the same way 🦋 Whenever a PA-TNC Attribute Type shows up on a network, it's always accompanied by an SMI Private Enterprise Number (PEN), also known as a vendor ID 🔢 If that vendor ID is zero, the PA-TNC Attribute Type is an IETF standard value listed in the IANA registry for PA-TNC Attribute Types, and its meaning is defined in the specification listed for that type in the registry 📖 If the vendor ID isn't zero, the meaning of the PA-TNC Attribute Type is defined by the vendor identified by that vendor ID (as listed in the IANA registry for SMI PENs) 🏢 That vendor is encouraged but not required to register some or all of the PA-TNC Attribute Types it uses with its vendor ID, and to publish a specification for each of those values 💜
this is basically the same idea as the one used for OIDs, and it's a delegation of namespace. It can cause interoperability problems if vendors require support for particular vendor-specific values 😬 But this specification explicitly prohibits that behavior (in section 4.1), which says: "Posture Collectors and Posture Validators MUST NOT require support for particular vendor-specific PA-TNC Attribute Types and MUST interoperate with other parties despite any differences in the set of vendor-specific PA-TNC Attribute Types supported (although they MAY permit administrators to configure them to require support for specific PA-TNC Attribute Types)". Similar requirements are included for PA Subtypes, Remediation Parameters Types, and PA-TNC Error Codes 🌟
7.1. Designated Expert Guidelines 💅
Okay so for all the IANA registries in this spec, new values get added by Expert Review with Specification Required, using the Designated Expert process from RFC 5226 [3]. 🎀
This section is a little pep talk for the designated experts so they can make calls with the right energy for these registries. ✨
The registries here have plenty of values. In most cases the IETF has approximately 2^32 values to define, and each vendor gets the same number for its own use. So bestie, designated experts should not be terribly concerned about running out. 🌸
What they should focus on instead: 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 instead agree on a single IETF standard value. That said, it is beneficial to document existing practice. 🦋
There are a few ways to make sure a specification is permanently and publicly available. It may be published as an RFC. Or it may be published some other way that makes it freely available to anyone. In that second case, 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 at some point the document stops being freely available to all through other channels. Very important, no cap. 👑
Section 7.2 defines the new PA Subtypes. The following three sections give the IANA guidance on creating and managing the new IANA registries defined by this specification. 🧚
7.2. PA Subtypes
Section 3.5 of this specification defines several new PA Subtypes that have been added to the PA Subtypes registry defined in the PB-TNC specification. Here's the list of assignments:
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 0 Testing RFC 5792
0 1 Operating System RFC 5792
0 2 Anti-Virus RFC 5792
0 3 Anti-Spyware RFC 5792
0 4 Anti-Malware RFC 5792
0 5 Firewall RFC 5792
0 6 IDPS RFC 5792
0 7 VPN RFC 5792
0 8 NEA Client RFC 5792These PA Subtypes have been added to the registry for PA Subtypes defined in the PB-TNC specification, with this RFC as the reference. ✨
7.3. Registry for PA-TNC Attribute Types
The name for this registry is "PA-TNC Attribute Types". Each entry in this registry should include a human-readable name, an SMI Private Enterprise Number, a decimal integer value between 0 and 2^32-1, and a reference to the specification where the contents of this attribute type are defined. This specification must define the meaning of this PA-TNC attribute type and the format and semantics of the PA-TNC Attribute Value field for PA-TNC attributes that include the designated Private Enterprise Number in the PA-TNC Attribute Vendor ID field and the designated numeric value in the PA-TNC Attribute Type field. 🎀
The following entries for this registry are defined in this document. They are the initial entries in the registry for PA-TNC Attribute Types. Additional entries are added by Expert Review with Specification Required, following the guidelines in section 7.1. 💜
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 0 Testing RFC 5792
0 1 Attribute Request RFC 5792
0 2 Product Information RFC 5792
0 3 Numeric Version RFC 5792
0 4 String Version RFC 5792
0 5 Operational Status RFC 5792
0 6 Port Filter RFC 5792
0 7 Installed Packages RFC 5792
0 8 PA-TNC Error RFC 5792
0 9 Assessment Result RFC 5792
0 10 Remediation Instructions RFC 5792
0 11 Forwarding Enabled RFC 5792
0 12 Factory Default Password RFC 5792
Enabled
0 0xffffffff Reserved RFC 57927.4. Registry for PA-TNC Error Codes
The name for this registry is "PA-TNC Error Codes". Each entry in this registry should include a human-readable name, an SMI Private Enterprise Number, a decimal integer value between 0 and 2^32-1, and a reference to the specification where this error code is defined. This specification must define the meaning of this error code and the format and semantics of the Error Information field for PA-TNC attributes that have a PA-TNC vendor ID of 0, a PA-TNC Attribute Type of PA-TNC Error, the designated Private Enterprise Number in the PA-TNC Error Code Vendor ID field, and the designated numeric value in the PA-TNC Error Code field. 🌈
The following entries for this registry are defined in this document. They are the initial entries in the registry for PA-TNC Error Codes. Additional entries are added by Expert Review with Specification Required, following the guidelines in section 7.1. 🫶
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 0 Reserved RFC 5792
0 1 Invalid Parameter RFC 5792
0 2 Version Not Supported RFC 5792
0 3 Attribute Type Not Supported RFC 57927.5. Registry for PA-TNC Remediation Parameters Types
The name for this registry is "PA-TNC Remediation Parameters Types". Each entry in this registry should include a human-readable name, an SMI Private Enterprise Number, a decimal integer value between 1 and 2^32-1, and a reference to the specification where the contents of this remediation parameters type are defined. This specification must define the meaning of this PA-TNC Remediation Parameters Type and the format and semantics of the Remediation Parameters field for PA-TNC attributes that include the designated Private Enterprise Number in the Remediation Parameters Vendor ID field and the designated numeric value in the Remediation Parameters Type field. 🍓
The following entries for this registry are defined in this document. They are the initial entries in the registry for PA-TNC Remediation Parameters Types. Additional entries are added by Expert Review with Specification Required, following the guidelines in section 7.1. 🦋
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 0 Reserved RFC 5792
0 1 URI RFC 5792
0 2 Remediation String RFC 57928. Acknowledgments 🫶
Thanks to the Trusted Computing Group for contributing the initial text [8] upon which this document was based. The authors would also like to acknowledge the following people, who contributed to or provided substantial input on the preparation of this document or predecessors to it: Stuart Bailey, Roger Chickering, Lauren Giroux, Charles Goldberg, Steve Hanna, Ryan Hurst, Meenakshi Kaushik, Greg Kazmierczak, Scott Kelly, PJ Kirner, Houcheng Lee, Lisa Lorenzin, Mahalingam Mani, Sung Lee, Ravi Sahita, Mauricio Sanchez, Brad Upson, and Han Yin. Everyone on this list is iconic. 👑
9. References 📚
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[4] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[5] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5793, March 2010.
[6] Phillips, A., Ed., and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
9.2. Informative References
[8] Trusted Computing Group, "IF-M: TLV Binding", http://www.trustedcomputinggroup.org/resources/tnc_ifm_tlv_binding_specification, February 2010.
[9] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, June 2008.
Appendix A. Use Cases ✨
A.1. Initial Client-Triggered Assessment ✨
okay so this scenario is about checking an endpoint's posture when it first joins the network 🧚. The Posture Broker Client (PBC) starts the assessment and collects patch info from two places: the Standard Operating System (OS) Posture Collector and a vendor-specific Patch Posture Collector (PC). Then both the vendor-specific Patch Posture Validator (PV) and the Standard OS Posture Validator check everything. Both come back compliant, so the Posture Broker Server (PBS) sends back a compliant System Assessment Decision. main character energy 💅
+--------+ +-------+ +---------+ +--------+ +-------++--------+
| Vndr. X| | Std. | | Std. | | Std. | | Std. || Vndr. X|
|Patch PC| | OS PC | | PBC | | PBS | | OS PV ||Patch PV|
+--+-----+ +-+-----+ +---+-----+ +-+------+ +-+------+--+-----+
| | 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 Reslt | | | |
| |<----------| | | |
| VndrX Patch Result | | | |
|<--------------------| | | |A.1.1. Message Contents
this part shows the juicy details of the key fields in each PA message from this use case 🔍. When it matters, 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 are shown for those. 🙈
A.1.1.1. N/W Join
this is the moment that makes the PBC decide to start assessing the endpoint so it can get network access 🚪. It's just an event, not an actual message being sent.
A.1.1.2. Request Posture (Req Post.)
this flow is when the OS and patch posture collectors get invoked and asked to send over certain posture attributes 📨. Since this use case gets triggered locally, NEA doesn't specify what's in this flow.
A.1.1.3. Vendor X Patch Posture (VndrX Patch Posture)
this flow carries the PA message from the Patch Posture Collector 🩷:
Vendor X Patch Posture PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=1 (vendor X)
type=1 (Vendor X namespace attribute)
length
Value = {
VendorXAttribute1=123
}
}
Attribute 2 {
vendor-id=1 (vendor X)
type=2 (Vendor X namespace attribute)
length
Value = {
VendorXAttribute2=456
}
}
}A.1.1.4. OS Posture
this flow carries the PA message from the OS Posture Collector 💻:
OS Posture PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=2 (product information)
length
Value = {
Product-vendor-id=311 -- Microsoft's PEN
Product-name="Windows Vista"
}
}
Attribute 2 {
vendor-id=0
type=3 (numeric version)
length
Value = {
major-version=6 -- Vista is version 6.0
minor-version=0
build-number=456789
service-pack-major=0 -- No service packs
service-pack-minor=0
}
}
}A.1.1.5. Posture Report
this flow is the PB message wrapping up the PA messages from the Patch and OS Posture Collectors 🎀. What's inside the message is described in the PB-TNC specification.
A.1.1.6. Verify Posture
this flow is when the OS and patch Posture Validators get invoked and asked to verify the posture attributes they received ✅. It all happens locally inside the NEA server, so NEA doesn't specify the message contents.
A.1.1.7. OS Posture Result (OS Reslt)
this flow carries the PA message (Posture Assessment Result) from the OS Posture Validator 🌸:
OS Posture Result PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=9 (assessment-result)
length
Value = {
assessment-result=0 (compliant)
}
}
}A.1.1.8. Vendor X Patch Result (VndrX Patch Result)
this flow carries the PA message (Posture Assessment Result) from the Vendor X Patch Posture Validator 🦋:
Patch Vendor X Posture Result PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=9 (assessment-result)
length
Value = {
assessment-result=0 (compliant)
}
}
}A.1.1.9. Assessment Result (Assess Result)
this flow is the PB message holding the system assessment result the Posture Broker Server computed, along with the PA messages from the Patch and OS Posture Validators 🏆. Its content is described in the PB-TNC specification.
A.1.1.10. Posture Result (OS PRslt & Vndr X Post PResult)
these flows are the OS and Vendor X Patch Posture Collectors getting invoked to receive the posture assessment results 💜. Since this flow is triggered locally, NEA doesn't specify what's in it.
A.2. Server-Initiated Assessment with Remediation
okay this one flips it around: the NEA Server starts the assessment instead of the endpoint 🔥. The Posture Broker Server triggers it and collects Anti-Virus attributes for two Anti-Virus components running on the endpoint. One vendor (Vendor X) anti-virus Posture Validator says the endpoint is compliant, but the other one (Vendor Y) says it's non-compliant 😬. Because of the Posture Broker Server's policy, the server returns a non-compliant system assessment decision. It also sends remediation instructions for the endpoint as part of the response, so it's not all doom and gloom 🫶.
+--------+ +-------+ +---------+ +--------+ +-------+ +--------+
| 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 Post 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 AV Post Result|
| | | |<---------+----------|
| | | |Vndr X AV | |
| | | |Post Reslt| |
| | | Assess |<---------| |
| | | Result | | |
| | Vndr X AV |<--------| | |
| |Post Reslt |<--------| | |
| |<----------| | | |
| Vndr Y AV Post Reslt | | | |
+<---------+-----------| | | |A.2.1. Message Contents
same deal as before: this part shows the key fields in each PA message from this use case 🧾. When needed, there's extra commentary on why the fields have the values they do. And yep, a bunch of these flows happen between components on the same system, so no message contents get shown for them. 🙈
A.2.1.1. N/W Join
this is the event that makes the PBS decide to start assessing the endpoint so it can get network access 🚪. It's just an event, not a message being sent.
A.2.1.2. Create Posture Request (Create Posture Req)
this flow is when the Vendor X and Vendor Y Anti-Virus Posture Validators get invoked and create the posture request attributes 🛡️. Since this use case is triggered locally, NEA doesn't specify what's in this flow.
A.2.1.3. Vendor Y AV Posture Request (Vndr Y AV Posture Req) 🦋
okay so this flow is the PA message (Posture Request) coming from the Vendor Y Anti-Virus Posture Validator 💅 it's the validator asking for very specific info, and it's giving main character energy 👑
Vendor Y AV Posture Request PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=1 (Attribute Request)
length
Value = {
Vendor-id=0 (IETF Standard)
Type=2 (Standard attribute, Product-Information)
Vendor-id=1 (Vendor Y)
Type=2 (Vendor Y attribute, Extended-Dat-Version)
}
}
}A.2.1.4. Vendor X AV Posture Request (Vndr X AV Post. Req) 🌸
same energy, different vendor, bestie 🫶 this flow is the PA message (Posture Request) from the Vendor X Anti-Virus Posture Validator ✨
Vendor X AV Posture Request PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=1 (Attribute Request)
length
Value = {
Vendor-id=1 (Vendor X)
Type=1 (Vendor X attribute, Scan-Engine-Version)
Vendor-id=0 (IETF Standard)
Type=5 (Standard, Operational-Status)
}
}
}A.2.1.5. Posture Request 💜
this one is the PB message that wraps up the PA messages from both the Vendor X and Vendor Y Anti-Virus Posture Validators 🎀 the actual message contents are described in the PB-TNC specification, so go check that if you want the nitty-gritty 🤓
A.2.1.6. Posture Request (Vndr X AV Post Req & Vndr Y AV Post Req) 🧚
these flows show the Vendor X and Vendor Y Anti-Virus Posture Collectors getting invoked to process the Posture Request and send back the specific posture attributes that were asked for ✨ ngl this one is a little bit of a plot twist, because this flow gets triggered locally, so NEA does not specify what's inside it 🙈
A.2.1.7. Vendor Y AV Posture (Vndr Y AV Posture) 🍓
this flow is the PA message (the response to the Posture Request) coming from the Vendor Y Anti-Virus Posture Collector 💖 it's basically "here's my whole glow-up" 💅
Vendor Y AV Posture PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0 (IETF Standard)
Type=2 (Standard attribute, Product-Information)
length
Value = {
product-vendor-id=12345 (vendor Y)
product-id=987 (AV product id from vendor Y)
product-name="Vendor Y Anti-Virus"
}
}
Attribute 2 {
vendor-id=2 (vendor Y)
type=2 (vendor Y attribute, DAT-Version)
length
Value = {
DAT-version=5678
}
}
}A.2.1.8. Vendor X AV Posture (Vndr X AV Posture) 🦋
same vibe, but from the Vendor X Anti-Virus Posture Collector 🌈 this is the PA message answering the Posture Request, and honestly the "never used" detail is so relatable 💀
Vendor X AV Posture PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=1
type=1 (vendor X attribute, Scan-Engine-Version)
length
Value = {
scan-engine-version=1234
}
}
Attribute 2 {
vendor-id=0 (IETF Standard)
type=5 (Standard, Operational-Status)
length
Value = {
status=2 (installed but non-operational)
result=0 (unknown)
last use="" (never used)
}
}
}A.2.1.9. Posture Response ⭐
this is the PB message that bundles the PA messages from the Vendor X and Vendor Y Anti-Virus Posture Collectors together 🫶 same deal as before: the message content lives in the PB-TNC specification 📖
A.2.1.10. Verify Posture ✅
this flow shows the Vendor X and Vendor Y Anti-Virus Posture Validators getting invoked to verify the posture attributes they received 💅 it happens locally inside the NEA server, so NEA does not specify the message contents, it's giving "private, do not disturb" 🤫
A.2.1.11. Vendor Y AV Posture Result (Vndr Y AV Post Result) 🎀
this flow is the PA message (Posture Assessment Result) from the Vendor Y Anti-Virus Posture Validator 🥰 and the verdict is a clean pass!
Vendor Y AV Posture Result PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=9 (assessment-result)
length
Value = {
assessment-result=0 (compliant)
}
}
}A.2.1.12. Vendor X AV Posture Result (Vndr X AV Post Reslt) 💀
and this is the PA message (Posture Assessment Result) from the Vendor X Anti-Virus Posture Validator, and... it's non-compliant 😭 not me being the one who has to explain this to my bestie
Vendor X AV Posture Result PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=9 (assessment-result)
length
Value = {
assessment-result=1 (non-compliant)
}
}
}A.2.1.13. Assessment Result (Assess Result) 👑
this flow is the PB message holding the system assessment result that the Posture Broker Server worked out, along with the PA messages from the Vendor X and Vendor Y Anti-Virus Posture Validators 💖 the message content is described in the PB-TNC specification, so that's where the receipts are ✨
A.2.1.14. Posture Result (Vndr X AV Post Reslt & Vndr Y AV Post Reslt) 🌸
these flows show the Vendor X and Vendor Y Anti-Virus Posture Collectors getting invoked to receive the posture assessment results 🧚 since this flow is triggered locally, NEA does not specify what's in it, so no spilling tea here 🫢
A.3. Client-Triggered Reassessment 🔥
okay this scenario is all about reassessing an endpoint because someone turned on a software component on it 💅 the endpoint has two VPN client software components: one from vendor X for the user's home network, and one from vendor Y for whatever network the endpoint is currently accessing 🌐 the assessment gets triggered when the user tries to use the Vendor X VPN client, and that's a violation of the assessment policy 🙈 the Posture Broker Client kicks off the posture assessment when it gets a notification from the VPN Posture Collector about the change to the operational state of the VPN component on the endpoint ✨ also, the VPN Posture Collector might support standard attributes plus some vendor-defined attributes from vendor X's and vendor Y's namespaces, but this use case doesn't use any vendor-defined attributes 🦋 the assessment involves verifying the standard VPN posture attributes with the standard VPN Posture Validator, and it results in a non-compliant assessment result 💀
This use case relies on using multiple Posture Collector IDs for a single Posture Collector, as described in section 3.3 of the PA-TNC specification 🫶 in this example, the Posture Collector gets two Posture Collector IDs for one single Posture Collector (Standard VPN PC), and it generates two separate PA messages, each using a different ID, to report the posture for the Vendor X and Vendor Y VPN Clients 💜 the Posture Broker Client associates the assigned IDs in the PB message it sends to the NEA Server 🎀 all of this is completely opaque to the NEA Server, which handles the PB message as if there were two VPN Posture Collectors on the NEA Client 🤯
+--------+ +-------+ +---------+ +--------+ +--------+ +--------+
|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 the contents of the key fields in each of the PA messages exchanged in this use case 💖 when it's needed, there's extra commentary explaining why certain fields have the values they do 🧠 heads up that a lot of the flows here 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 merely an event, so no message gets sent
A.3.1.2. Notify Status Change (VPN Status Change) 👀
this flow is the VPN Posture Collector noticing that the Vendor X VPN Client software has become active 🌟 again, just an event, no message 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 💅 merely an event, so no message is sent here either
A.3.1.4. Request Posture (Req. Post) 🧚
this flow shows the VPN Posture Collector being invoked to request particular posture attributes be sent 🫶 since this use case is triggered locally, NEA does not specify the contents of this flow
A.3.1.5. Inspect/Request Info (Ins/Rq Info) 🔍
this flow is the VPN Posture Collector acquiring posture info from the Vendor X and Vendor Y VPN Client components 💜 because it's triggered locally, NEA does not specify the message contents
A.3.1.6. Vendor X VPN Posture (VPNX Post) 💖
this flow contains the PA message from the VPN Posture Collector describing the Vendor X VPN Client's posture, and it's giving full-on glam 💅✨
Vendor X VPN Posture PA Message{
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=2 (product information)
length
Value = {
product-vendor-id=9876 (vendor X)
product-id=567 (VPN client identifier for Vndr X)
product-name="Vendor X VPN Client"
}
}
Attribute 2 {
vendor-id=0
type=5 (operational status)
length
Value = {
Status=3 (Operational)
Result=1 (Successful use with no errors detected)
last Use="2008-07-07T12:00:00Z"
}
}A.3.1.7. Vendor Y VPN Posture (VPNY Post) 💖
okay bestie, this flow is the PA message coming from the VPN Posture Collector, and it's carrying the Vendor Y VPN Client's posture 🦋
Vendor Y VPN Posture PA Message{
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=2 (product information)
length
Value = {
product-vendor-id=Vendor Y
product-id=234 (VPN client identifier for Vndr Y)
product-name="Vendor Y VPN Client"
}
}
Attribute 2 {
vendor-id=0
type=5 (operational status)
length
Value = {
Status=3 (Operational)
Result=1 (Successful use with no errors detected)
last Use="2008-07-07T14:05:00Z"
}
}
}A.3.1.8. Posture Report 🎀
this one is the PB message that wraps the PA message from the VPN Posture Collector 📦 the message content is described in the PB-TNC specification, so go there for the deets ✨
A.3.1.9. Verify Posture (Vrfy Post.) 🔍
this flow is the VPN Posture Validator being asked to verify the posture attributes it received 💅 it happens locally inside the NEA Server, so NEA doesn't specify the message contents. it's giving "private business" energy 🙈
A.3.1.10. VPN Posture Result (VPN PRslt) 📝
this flow has the PA message (Posture Assessment Result) coming back from the VPN Posture Validator 💜
VPN Posture Result PA Message {
Attribute HDR {Message ID}
Attribute 1 {
vendor-id=0
type=9 (assessment-result)
length
Value = {
assessment-result=1 (non-compliant)
}
}
}oof, non-compliant 😭 the client didn't pass this time.
A.3.1.11. Assessment Result (Assess Result) 🌸
this flow is the PB message holding the system assessment result that the Posture Broker Server computed, plus the PA messages from the VPN Posture Validator 🧚 the message content is described in the PB-TNC specification, so again, that's where you look 🫶
A.3.1.12. Posture Result (VPN PRslt) 👑
this flow is the VPN Posture Collector receiving the posture assessment result ✨ because it gets triggered locally, NEA doesn't specify what's in this flow. main character energy from the local side 💖
Appendix B. Evaluation against NEA Requirements 🦋
bestie, this section checks PA-TNC against the requirements in the NEA Requirements document 🔥 each subsection looks at one separate requirement. only the common ones (C-1 through C-10) and the PA ones (PA-1 through PA-6) get considered, since those are the only ones that apply to PA 💅
B.1. Evaluation against Requirement C-1 🌈
okay so the requirement says:
C-1 NEA protocols MUST support multiple round trips between the NEA
Client and NEA Server in a single assessment.PA-TNC totally meets this one 💖 it allows an unlimited number of round trips between the NEA Client and NEA Server ✨
B.2. Evaluation against Requirement C-2 🎀
the requirement 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.PA-TNC meets this requirement 🫶 it's designed to work whether the NEA Client or the NEA Server starts a posture assessment or reassessment. both sides get a seat at the table 🍓
B.3. Evaluation against Requirement C-3 🔐
the requirement 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.okay this one is a little plot twist 😭 security for PA-TNC messages sent over the network is provided through PT protocol security. so PA-TNC doesn't include any security capabilities of its own 💀 since this requirement only applies to NEA protocols "including security capabilities", this specification is not subject to this requirement (see section 5.2). iykyk 🙈
B.4. Evaluation against Requirement C-4 🧚
the requirement 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).PA-TNC meets this requirement 💜 it can operate over any PT protocol that meets the requirements for PT stated in the NEA Requirements document. it doesn't have any dependencies on specific details of the underlying PT protocol, so it's super flexible 🦋
B.5. Evaluation against Requirement C-5 📚
the requirement 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.so based on this one, PA-TNC should receive a strong preference ✨ PA-TNC is equivalent with IF-M 1.0, an open TCG specification 🌸 other specifications from TCG and other groups are also under development based on the IF-M 1.0 specification. picking PA-TNC as the basis for the PA protocol keeps things compatible with IF-M 1.0, with these other specifications, and with their implementations. no reinventing the wheel, periodt 💅
B.6. Evaluation against Requirement C-6 🌟
the requirement 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.PA-TNC meets this requirement, and honestly it's iconic 👑 it supports an unlimited number of Posture Collectors, Posture Validators, NEA Clients, and NEA Servers. it's also quite scalable in lots of other ways too 🔥 a PA-TNC message can contain up to 2^32-1 octets and about 2^28 PA-TNC attributes. each organization with an SMI Private Enterprise Number is entitled to define up to 2^32 vendor-specific PA-TNC Attribute Types, 2^16 vendor-specific PA-TNC Product IDs, and 2^32 vendor-specific PA-TNC Error Codes. each attribute can contain almost 2^32 octets. it's generally not advisable or necessary to send this much data in a NEA assessment, but still, PA-TNC is highly scalable and meets requirement C-6 easily 💖
B.7. Evaluation against Requirement C-7 🦋
the requirement says:
C-7 The protocols MUST support efficient transport of a large
number of attribute messages between the NEA Client and the NEA
Server.PA-TNC meets this one ✨ each PA-TNC message can contain about 2^28 PA-TNC attributes. PA-TNC supports up to 2^32 round trips in a session, so the maximum number of attribute messages that can be sent in a single session is actually about 2^50. that's a lot, bestie 😭 however, it's generally inadvisable and unnecessary to send a large number of messages in a NEA assessment. as for efficiency, PA-TNC adds only 12 octets of overhead per attribute and 8 octets per message, which is negligible on a per-attribute basis 🧚
B.8. Evaluation against Requirement C-8 🌸
the requirement says:
C-8 NEA protocols MUST operate efficiently over low bandwidth or
high latency links.PA-TNC meets this requirement 🍓 a PA-TNC exchange is envisioned (based on current deployment experience) to involve one or two round trips with less than 500 octets of PA-TNC messages. of course, using vendor-specific PA-TNC attribute types could expand the assessment. still, PA-TNC itself only imposes an overhead of 8 octets per PA-TNC message and 12 octets per attribute, so it stays light 🫶
B.9. Evaluation against Requirement C-9 🌈
the requirement 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.PA-TNC meets this requirement 💜 the only field included in a PB-TNC attribute for display to the user includes a language tag, which could be selected based upon the user's PB-TNC negotiated preferred language for the assessment (see section 4.10 of the PB-TNC specification). with this exception, all of the strings in the standard PA-TNC attributes are intended for logging and programmatic comparisons 🤓
if any vendor-specific PA-TNC attribute types or future IETF Standard PA-TNC Attribute Types include strings intended for display to a user, they should be translated to the user's preferred language 🌍 the Posture Broker Server will need to expose the user's preferences to the Posture Validators through whatever API or protocol is used to connect those components. however, that is all out of scope for this specification 🙈
B.10. Evaluation against Requirement C-10 🎀
the requirement says:
C-10 NEA protocols MUST support encoding of strings in UTF-8 format.PA-TNC meets this one 🦋 all strings in the PA-TNC protocol are encoded in UTF-8 format. this lets the protocol support a wide range of languages efficiently 🌏✨
B.11. Evaluation against Requirement C-11 🔥
the requirement 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.PA-TNC meets this requirement 💖 the design emphasizes efficient transport of information so it's usable in constrained PT environments. local APIs could let Posture Collectors and Posture Validators discover when they're operating in a less constrained deployment, and then use more verbose attributes. similarly, Posture Collectors could choose not to send or use smaller attributes (including assertions from previous assessments) when facing a very constrained network connection 🧚
B.12. Evaluation against Requirement PA-1 👑
the requirement says:
PA-1 The PA protocol MUST support communication of an extensible set
of NEA standards-defined attributes. These attributes will be
uniquely identifiable from non-standard attributes.PA-TNC meets this one, and it's giving organized 📚 each attribute is identified with a PA-TNC Attribute Vendor ID and a PA-TNC Attribute Type. IETF Standard PA-TNC Attribute Types use a vendor ID of zero (0), while vendor-specific PA-TNC Attribute Types use the vendor's SMI Private Enterprise Number as the vendor ID. the IANA will maintain a registry of PA-TNC Attribute Types, with new values added by Expert Review with Specification Required, as described in the IANA Considerations section of this specification. so the set of standard attribute types is extensible, but every standard attribute type is still uniquely identifiable 🌈✨
B.13. Evaluation against Requirement PA-2 💜
okay so the requirement says:
PA-2 The PA protocol MUST support communication of an extensible set of vendor-specific attributes. These attributes will be segmented into uniquely identifiable vendor-specific namespaces.
PA-TNC totally meets this one 💅✨ every attribute gets tagged with a PA-TNC Attribute Vendor ID and a PA-TNC Attribute Type. When a vendor defines its own attribute types, it uses its SMI Private Enterprise Number as the Vendor ID. Each vendor can define up to 2^32 PA-TNC Attribute Types and manage them with its own internal processes 🎀
IANA isn't really involved here, except for handing out the vendor's SMI Private Enterprise Number at the start. So the whole set of vendor-specific attributes ends up split into namespaces that are each uniquely identifiable 🦋 iconic, honestly.
B.14. Evaluation against Requirement PA-3 🧚
Requirement PA-3 says:
PA-3 The PA protocol MUST enable a Posture Validator to make one or more requests for attributes from a Posture Collector within a single assessment. This enables the Posture Validator to reassess the posture of a particular endpoint feature or to request additional posture including from other parts of the endpoint.
PA-TNC meets this too ✨ the Attribute Request attribute type is an IETF Standard PA-TNC Attribute Type, and it lets a Posture Validator ask one or more Posture Collectors for one or more attributes 🌸 it can be sent at any point in the assessment, and it can even be sent more than once. For example, the validator might first figure out what operating system the endpoint is running, then ask for attributes that are specific to that OS. Main character energy 👑
B.15. Evaluation against Requirement PA-4 🍓
Requirement PA-4 says:
PA-4 The PA protocol MUST be capable of returning attributes from a Posture Validator to a Posture Collector. For example, this might enable the Posture Collector to learn the specific reason for a failed assessment and to aid in remediation and notification of the system owner.
PA-TNC meets this one as well 🫶 a Posture Validator can easily send attributes back to one or more Posture Collectors. Super simple, no drama.
B.16. Evaluation against Requirement PA-5 🔒
Requirement PA-5 says:
PA-5 The PA protocol SHOULD provide authentication, integrity, and confidentiality of attributes communicated between a Posture Collector and Posture Validator. This enables end-to-end security across a NEA deployment that might involve traversal of several systems or trust boundaries.
okay so PA-TNC doesn't have its own explicit PA-level security mechanism 🥺 BUT it does lay a foundation so attribute-level protections can be added later on 🌈 the NEA working group actually looked at an Internet-Draft that wrapped PA attributes in a Cryptographic Message Syntax (CMS) security wrapper inside a new attribute type. That proposal would have given the protections this requirement describes. The WG said nope, the use cases in scope didn't need PA-level security 💀 the ones where PA messages go through several systems or trust boundaries were called out of scope, so end-to-end protection between Posture Validator and Posture Collector was judged not required.
Instead, PA-TNC attributes are protected by the authentication, integrity, and confidentiality support in the PT layer 🔐 that covers the attributes passing between the Posture Transport Client and the Posture Transport Server. Here's the logic: the Posture Collector lives in the same address space as the Posture Broker Client and Posture Transport Client, and the Posture Validator lives in the same address space as the Posture Broker Server and Posture Transport Server. So the broker and transport components are considered trusted not to tamper with PA messages (check the trust model in section 5.1 for the details ✨). Encrypting the PA-TNC messages wouldn't stop a hostile broker or transport component from attacking them anyway, so it wouldn't really help 🙈
B.17. Evaluation against Requirement PA-6 🌸
Requirement PA-6 says:
PA-6 The PA protocol MUST be capable of carrying attributes that contain non-binary and binary data including encrypted content.
And PA-TNC meets this one ✅ PA-TNC attributes can hold both non-binary and binary data, including encrypted content 🔥 check out the attribute type definitions in this specification for examples.
Authors' Addresses 🎀
Paul Sangster
Symantec Corporation
6825 Citrine Drive
Carlsbad, CA 92009
USA
EMail: Paul_Sangster@symantec.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: rfc5792 2010-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms