idnits 2.17.1 draft-ietf-nea-pa-tnc-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 22, 2009) is 5298 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (ref. '3') (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 4646 (ref. '6') (Obsoleted by RFC 5646) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Sangster 3 Internet Draft Symantec Corporation 4 Intended status: Proposed Standard K. Narayan 5 Expires: April 2010 Cisco Systems 7 October 22, 2009 9 PA-TNC: A Posture Attribute Protocol (PA) Compatible with TNC 10 draft-ietf-nea-pa-tnc-06.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance 15 with the provisions of BCP 78 and BCP 79. This document may 16 contain material from IETF Documents or IETF Contributions 17 published or made publicly available before November 10, 2008. 18 The person(s) controlling the copyright in some of this material 19 may not have granted the IETF Trust the right to allow 20 modifications of such material outside the IETF Standards 21 Process. Without obtaining an adequate license from the 22 person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, 24 and derivative works of it may not be created outside the IETF 25 Standards Process, except to format it for publication as an RFC 26 or to translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet 29 Engineering Task Force (IETF), its areas, and its working 30 groups. Note that other groups may also distribute working 31 documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other 35 documents at any time. It is inappropriate to use Internet- 36 Drafts as reference material or to cite them other than as "work 37 in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on August 22, 2009. 47 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license- 54 info). Please review these documents carefully, as they describe 55 your rights and restrictions with respect to this document. 57 Abstract 59 This document specifies PA-TNC, a Posture Attribute Protocol 60 identical to the Trusted Computing Group's IF-M 1.0 protocol. 61 The document then evaluates PA-TNC against the requirements 62 defined in the NEA Requirements specification. 64 Table of Contents 66 1. Introduction...................................................5 67 1.1. Prerequisites.............................................5 68 1.2. Message Diagram Conventions...............................5 69 1.3. Conventions Used in this Document.........................5 70 2. Design Considerations..........................................5 71 2.1. Standard Attribute Namespace for Interoperability.........6 72 2.2. Vendor Defined Namespace for Differentiation and Agility..6 73 2.3. Use of TLV Based Encoding for Efficiency..................7 74 3. PA-TNC Message Protocol........................................8 75 3.1. PA-TNC Messaging Model....................................8 76 3.2. PA-TNC Relationship to PB-TNC.............................9 77 3.3. PB-PA Posture Collector and Posture Validator Identifiers11 78 3.4. PA-TNC Messages in PB-TNC................................12 79 3.5. IETF Standard PA Subtypes................................12 80 3.6. PA-TNC Message Header Format.............................14 81 4. PA-TNC Attributes.............................................15 82 4.1. PA-TNC Attribute Header..................................15 83 4.2. IETF Standard PA-TNC Attribute Types.....................19 84 4.2.1. Attribute Request...................................20 85 4.2.2. Product Information.................................23 86 4.2.3. Numeric Version.....................................25 87 4.2.4. String Version......................................27 88 4.2.5. Operational Status..................................29 89 4.2.6. Port Filter.........................................32 90 4.2.7. Installed Packages..................................34 91 4.2.8. PA-TNC Error........................................37 92 4.2.8.1. Invalid Parameter Error Code...................39 93 4.2.8.2. Version Not Supported Error Code...............41 94 4.2.8.3. Attribute Type Not Supported Error Code........42 96 4.2.9. Assessment Result...................................44 97 4.2.10. Remediation Instructions...........................45 98 4.2.10.1. Remediation URI Parameters....................47 99 4.2.10.2. Remediation String Parameters Type............48 100 4.2.11. Forwarding Enabled.................................49 101 4.2.12. Factory Default Password Enabled...................50 102 4.3. Vendor-Defined Attributes................................52 103 5. Security Considerations.......................................52 104 5.1. Trust Relationships......................................52 105 5.1.1. Posture Collector...................................53 106 5.1.2. Posture Validator...................................53 107 5.1.3. Posture Broker Client, Posture Broker Server........53 108 5.2. Security Threats.........................................54 109 5.2.1. Attribute Theft.....................................54 110 5.2.2. Message Fabrication.................................55 111 5.2.3. Attribute Modification..............................56 112 5.2.4. Attribute Replay....................................56 113 5.2.5. Attribute Insertion.................................57 114 5.2.6. Denial of Service...................................57 115 6. Privacy Considerations........................................57 116 7. IANA Considerations...........................................59 117 7.1. Designated Expert Guidelines.............................60 118 7.2. PA Subtypes..............................................60 119 7.3. Registry for PA-TNC Attribute Types......................61 120 7.4. Registry for PA-TNC Error Codes..........................62 121 7.5. Registry for PA-TNC Remediation Parameters Types.........63 122 8. Acknowledgments...............................................63 123 9. References....................................................64 124 9.1. Normative References.....................................64 125 9.2. Informative References...................................64 126 Appendix A: Use Cases............................................64 127 A.1. Initial Client triggered assessment......................64 128 A.1.1. Message Contents....................................65 129 A.1.1.1. N/W Join.......................................66 130 A.1.1.2. Request Posture (Req Post.)....................66 131 A.1.1.3. Vendor X Patch Posture (VndrX Patch Posture)...66 132 A.1.1.4. OS Posture.....................................66 133 A.1.1.5. Posture Report.................................67 134 A.1.1.6. Verify Posture.................................67 135 A.1.1.7. OS Posture Result (OS Reslt)...................67 136 A.1.1.8. Vendor X Patch Result (VndrX Patch Result).....68 137 A.1.1.9. Assessment Result (Assess Result)..............68 138 A.1.1.10. Posture Result (OS PRslt & Vndr X Post 139 PResult)......................................68 140 A.2. Server initiated Assessment with Remediation.............68 141 A.2.1. Message Contents....................................70 142 A.2.1.1. N/W Join.......................................70 143 A.2.1.2. Create Posture Request (Create Posture Req.)...70 144 A.2.1.3. Vendor Y AV Posture Request (Vndr Y AV Posture 145 Req)...........................................70 146 A.2.1.4. Vendor X AV Posture Request (Vndr X AV Post. 147 Req)...........................................71 148 A.2.1.5. Posture Request................................71 149 A.2.1.6. Posture Request (Vndr X AV Post Req & Vndr Y AV 150 Post Req)......................................71 151 A.2.1.7. Vendor Y AV Posture (Vndr Y AV Posture)........71 152 A.2.1.8. Vendor X AV Posture (Vndr X AV Posture)........72 153 A.2.1.9. Posture Response...............................73 154 A.2.1.10. Verify Posture................................73 155 A.2.1.11. Vendor Y AV Posture Result (Vndr Y AV Post 156 Result).......................................73 157 A.2.1.12. Vendor X AV Posture Result (Vndr X AV Post 158 Reslt)........................................73 159 A.2.1.13. Assessment Result (Assess Result).............74 160 A.2.1.14. Posture Result (Vndr X AV Post Reslt & Vndr Y 161 AV Post Reslt)................................74 162 A.3. Client triggered re-assessment...........................74 163 A.3.1. Message Contents....................................75 164 A.3.1.1. Enable VPN Client (Enble)......................76 165 A.3.1.2. Notify Status Change (VPN Status Change).......76 166 A.3.1.3. Notify Posture Change (Posture Change).........76 167 A.3.1.4. Request Posture (Req. Post)....................76 168 A.3.1.5. Inspect/Request Info (Ins/Rq Info).............76 169 A.3.1.6. Vendor X VPN Posture (VPNX Post)...............76 170 A.3.1.7. Vendor Y VPN Posture (VPNY Post)...............77 171 A.3.1.8. Posture Report.................................78 172 A.3.1.9. Verify Posture (Vrfy Post.)....................78 173 A.3.1.10. VPN Posture Result (VPN PRslt)................78 174 A.3.1.11. Assessment Result (Assess Result).............78 175 A.3.1.12. Posture Result (VPN PRslt)....................78 176 B.1. Evaluation Against Requirements C-1......................79 177 B.2. Evaluation Against Requirements C-2......................79 178 B.3. Evaluation Against Requirements C-3......................79 179 B.4. Evaluation Against Requirements C-4......................80 180 B.5. Evaluation Against Requirements C-5......................80 181 B.6. Evaluation Against Requirements C-6......................80 182 B.7. Evaluation Against Requirements C-7......................81 183 B.8. Evaluation Against Requirements C-8......................81 184 B.9. Evaluation Against Requirements C-9......................81 185 B.10. Evaluation Against Requirements C-10....................82 186 B.11. Evaluation Against Requirements C-11....................82 187 B.12. Evaluation Against Requirements PA-1....................83 188 B.13. Evaluation Against Requirements PA-2....................83 189 B.14. Evaluation Against Requirements PA-3....................84 190 B.15. Evaluation Against Requirements PA-4....................84 191 B.16. Evaluation Against Requirements PA-5....................84 192 B.17. Evaluation Against Requirements PA-6....................85 193 Authors' Addresses...............................................86 195 1. Introduction 197 This document specifies PA-TNC, a Posture Attribute Protocol 198 (PA) identical to the Trusted Computing Group's IF-M 1.0 199 protocol [8]. The document then evaluates PA-TNC against the 200 requirements defined in the NEA Requirements specification [9]. 202 1.1. Prerequisites 204 This document does not define an architecture or reference 205 model. Instead, it defines a protocol that works within the 206 reference model described in the NEA Overview and Requirements 207 specification. The reader is assumed to be thoroughly familiar 208 with that document. No familiarity with TCG specifications is 209 assumed. 211 1.2. Message Diagram Conventions 213 This specification defines the syntax of PA-TNC messages using 214 diagrams. Each diagram depicts the format and size of each 215 field in bits. Implementations MUST send the bits in each 216 diagram as they are shown, traversing the diagram from top to 217 bottom and then from left to right within each line (which 218 represents a 32-bit quantity). Multi-byte fields representing 219 numeric values must be sent in network (big endian) byte order. 221 Descriptions of bit field (e.g. flag) values are described 222 referring to the position of the bit within the field. These 223 bit positions are numbered from the most significant bit through 224 the least significant bit so a one octet field with only bit 0 225 set has the value 0x80. 227 1.3. Conventions Used in this Document 229 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 230 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 231 "OPTIONAL" in this document are to be interpreted as described 232 in RFC 2119 [1]. 234 2. Design Considerations 236 This section discusses some of the key design considerations for 237 the PA protocol. 239 2.1. Standard Attribute Namespace for Interoperability 241 The PA protocol requires the use of two categories of 242 namespaces: component types (AKA PA Subtypes) and attributes. 243 Each of these namespace categories needs to contain well known, 244 interoperable names with defined syntax and semantics co- 245 existing with names for vendor defined private extensions. 246 Similarly, each namespace category needs to be readily 247 extensible without repeated coordination yet avoids naming 248 conflicts. 250 The PA-TNC and PB-TNC protocols provide for multiple orthogonal 251 namespaces for each category that exist without overlap by 252 including a SMI Private Enterprise Number (PEN) field to 253 identify the definer of namespace of the associated field. This 254 allows the IETF NEA WG to define a set of standard component 255 types and attribute types while allowing vendors to each create 256 additional names outside of the IETF standard namespace. Over 257 time, vendor defined names might be proposed for standardization 258 and thus migration into the IETF namespace. 260 The PB-TNC protocol defines an IETF standard namespace (using 261 vendor-id=0) that allows for definition of standard component 262 types (e.g. Operating System, Firewall, Anti-Virus) using the PA 263 Subtype field (see section 3.2). Similarly, PA-TNC defines a 264 set of standard attributes in section 4.2 that represent the 265 most common capabilities (attributes) of these types of 266 components across a variety of vendor implementations. The 267 standard namespace allows NEA deployments with both open source 268 and vendor provided NEA implementations to support a consistent 269 set of policies across their environment based on these standard 270 attributes. The standard attributes can be used with a variety 271 of endpoints (hosts, printers, mobile devices) that are running 272 applications and operating systems (defined by the PA Subtypes) 273 from a variety of vendors. 275 2.2. Vendor Defined Namespace for Differentiation and Agility 277 The endpoint is a very dynamic environment in terms of rate of 278 new features being deployed and attacks that are crafted against 279 existing and new applications such as: viruses, worms, malware, 280 and spyware. It is difficult to imagine the standard namespaces 281 to being able to keep pace with this rapidly changing 282 environment. Vendors typically differentiate themselves by 283 moving rapidly to provide unique mechanisms to address such 284 threats and their ability to deal with changes in an agile 285 manner. The PA-TNC and PB-TNC protocols allows for creation of 286 vendor defined namespace(s) where each namespace allows use of 287 vendor defined PA Subtypes to identify non-standard applications 288 or operating system variants and vendor defined attributes 289 describing new aspects of each type of component. The vendor 290 namespaces will allow NEA deployments to craft compliance 291 policies using a mixture of attributes from both the IETF 292 standard namespace and vendor defined namespaces that may 293 include multiple vendors representing the various hardware and 294 software components present on the endpoints. 296 The PA-TNC protocol's use of vendor-id to identify the namespace 297 of each attribute allows Posture Collectors to support some or 298 all of the IETF standard attributes plus optionally a set of 299 vendor defined attributes (potentially from more then one 300 vendor-id namespace). For instance, an open source anti-virus 301 Posture Collector might be written that supports all of the IETF 302 standard attributes used to describe a local anti-virus 303 component and a subset of multiple anti-virus manufacturers' 304 vendor defined attributes. This Posture Collector might 305 therefore be able to interoperate with Posture Validators from 306 multiple vendors. Conversely, a simple Posture Collector might 307 be written to ignore any vendor defined attributes requested and 308 only return standard attributes that it supports. If the vendor 309 provided Posture Validator's policy allows for this subset to be 310 considered compliant, then these simple Posture Collectors can 311 be used to perform a successful assessment. 313 2.3. Use of TLV Based Encoding for Efficiency 315 The PA-TNC protocol has chosen to employ a binary encoding using 316 a type-length-value (TLV) structure. TLV encoding was preferred 317 over the use of a textual encoding format such as XML to provide 318 a more efficient utilization of the potentially constrained 319 bandwidth available between the NEA Client and NEA Server (see 320 NEA Overview and Architecture [9]). Efficiency was a primary 321 criterion for this choice with consideration given to both: 323 1. Optimization of the bits-on-the-wire to accommodate NEA 324 requirements for assessment over low bandwidth or high 325 latency links (C-8) and allow for the PT protocol to run 326 over existing network access protocols (PT-4, C-11) that 327 are constrained by packet size. 329 2. Optimization of CPU utilization on the endpoint to 330 accommodate for low power endpoints such as mobile devices. 332 The choice of TLV encoding does not preclude the use of XML- 333 based attribute values within the vendor namespaces or future 334 standard attributes. It is conceivable that certain vendors may 335 utilize XML encoding for extensibility within their namespace 336 when the above considerations are less applicable to their 337 technologies. Attributes encoded within the vendor defined 338 namespace using alternate encoding such as XML will be opaque to 339 NEA software only supporting standard attributes and will be 340 processed primarily by the vendor defined components 341 (collector/validator). 343 3. PA-TNC Message Protocol 345 This section discusses the use of the PA-TNC message and its 346 attributes, and specifies the syntax and semantics for the PA- 347 TNC message header. The details of each attribute included 348 within the PA-TNC payload are specified in section 4.2. 350 3.1. PA-TNC Messaging Model 352 PA-TNC messages are carried by the PB-TNC protocol [5], which 353 provides a multi-roundtrip reliable transport and end-to-end 354 message delivery to subscribed (interested) parties using a 355 variety of underlying network protocols. PA-TNC is unaware of 356 these underlying PT transport protocols being used below PB-TNC. 358 The interested parties consist of Posture Collectors on the NEA 359 Client and Posture Validators associated with the NEA Server 360 that have registered to receive messages about particular types 361 of components (e.g. anti-virus) during an assessment. The PA- 362 TNC messaging protocol operates synchronously within an 363 assessment session, with Posture Collectors and Posture 364 Validators taking turns sending one or more messages to each 365 other. Each PA-TNC message may contain one or more attributes 366 associated with the functional component identified in the 367 component type (PA Subtype) of the PB protocol. 369 Posture Collectors may only send PA-TNC messages to Posture 370 Validators and vice versa. No Posture Collector to Posture 371 Collector or Posture Validator to Posture Validator messaging is 372 allowed to occur. Each Posture Collector or Posture Validator 373 may send several PA-TNC messages in succession before indicating 374 that it has completed its batch of messages to the Posture 375 Broker Client or Posture Broker Server respectively. As 376 necessary, the Posture Broker Client and Posture Broker Server 377 will batch these messages prior to sending them over the 378 network. 380 PB-TNC provides a publish/subscribe model of message exchange. 381 This means that, at any given point in time, zero or more 382 subscribers for a particular type of message may be present on a 383 Posture Broker Client or Posture Broker Server. This is 384 beneficial, since it allows one Posture Collector or Posture 385 Validator to combine multiple functions (like anti-virus and 386 personal firewall) by subscribing to both TNC standard component 387 types. It also allows multiple Posture Collectors or Posture 388 Validators to support the same components, such as two anti- 389 virus Posture Validators that are each used to manage their own 390 respective anti-virus client software. 392 However, this publish/subscribe model has some possible negative 393 side effects. When a Posture Collector or Posture Validator 394 initially sends a PA-TNC message, it does not know whether it 395 will receive many, one, or no PA-TNC messages from the other 396 side. For many types of assessments, this is acceptable, but in 397 some cases a more direct channel binding between a particular 398 Posture Collector and Posture Validator pair is necessary. For 399 example, a Posture Validator may wish to provide remediation 400 instructions to a particular Posture Collector that it knows is 401 capable of remediating a non-compliant component. This can be 402 accomplished using the exclusive delivery PB-TNC capability to 403 limit distribution of a message to a single Posture Collector by 404 including the target Posture Collector Identifier in the PB-PA 405 header. For more information on the PB-PA header, see section 406 4.5 of the PB-TNC specification. 408 3.2. PA-TNC Relationship to PB-TNC 410 This section summarizes the major elements of a PA-TNC message 411 as they might appear inside of a PB-TNC message. The double 412 line (===) in the diagram below indicates the separation between 413 the PB-TNC and PA-TNC protocols. The PA-TNC portion of the 414 message is delivered to each Posture Collector or Posture 415 Validator registered to receive messages containing a particular 416 message type. Note that PB-TNC is capable of carrying multiple 417 PB-TNC and PA-TNC messages in a single PB-TNC batch. See the 418 PB-TNC specification [5] for more information on its 419 capabilities. 421 One important linkage between the PA-TNC and PB-TNC protocols is 422 the PA message type (PA Message Vendor ID and PA Subtype) that 423 is used by the Posture Broker Client and Posture Broker Server 424 to route messages to interested Posture Collectors and Posture 425 Validators. The message type indicates the software component 426 (component type) that is associated with the attributes included 427 inside the PA-TNC message. Therefore, Posture Collectors and 428 Posture Validators written to support an assessment of a 429 particular component can register to receive messages about the 430 component and thus participate in its assessment. Each Posture 431 Collector and Posture Validator MUST only send PA-TNC messages 432 containing attributes that pertain to the software component 433 defined in the message type of the message. This ensures that 434 only the appropriate Posture Collectors and Posture Validators 435 that support a particular type of component will receive 436 attributes related to that component. If a PA-TNC message 437 contained a mix of attributes about different components and a 438 message type of only one of those components, the message would 439 only be delivered to parties interested in the component type 440 included in the message type, so other interested recipients 441 wouldn't see those attributes. 443 The message type is comprised of 2 fields: a PA Message Vendor 444 ID and a PA Subtype. The PA Message Vendor ID identifies the 445 vendor or other organization that defined this message type. 446 The PA Subtype identifies the message type more specifically 447 within the set of message types defined by that vendor. This 448 specification defines several IETF Standard PA Subtypes to be 449 used with a PA Message Vendor ID of zero (0). Within this 450 specification, the PA Subtype field is used to indicate the type 451 of component (e.g. firewall) involved with the message's 452 attributes. Therefore for clarity the PA subtype will be 453 referred to as the "component type" in this specification. 454 Vendor-defined name spaces may use other semantics for the PA 455 Subtype field as this is outside the scope of this 456 specification. 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | PB-TNC Header | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | PB-TNC Message of type PB-PA-Message | 462 |(includes: PA Message Vendor ID, PA Subtype, and other fields| 463 | used by Posture Broker Client and Posture Broker Server for | 464 | routing) | 465 =============================================================== 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | PA-TNC Message Header | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | PA-TNC Attribute | 470 | (e.g. Product Information) | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | PA-TNC Attribute | 473 | (e.g. Operational Status) | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 Figure 1 Overview of a PB-TNC batch that contains a PA-TNC 477 Message 479 For example, if a Posture Broker Client sent a PB-TNC batch that 480 contained a PA-TNC message with a message type indicating 481 firewall component, this message would be routed by the Posture 482 Broker Server to Posture Validators registered to assess 483 firewalls. Each registered Posture Validator would receive a 484 copy of the PA-TNC message including the PA-TNC header and set 485 of attributes. It is important that each of the attributes 486 included in the PA-TNC message be associated with the firewall 487 component because only the Posture Collector and Posture 488 Validator interested in firewalls will receive such messages. 490 If the above message contained both firewall and operating 491 system attributes inside a PA-TNC message with a component type 492 of firewall, then any Posture Collector and Posture Validator 493 registered to receive operating system messages would not 494 receive those attributes, as the messages would only be 495 delivered to those registered for firewall messages. 497 3.3. PB-PA Posture Collector and Posture Validator Identifiers 499 The PB-PA header contains several fields important to the 500 processing of a received PA message. The PA Vendor ID and 501 Subtype are described in the PB-TNC specification and above in 502 section 3.2. Also present in the PB-PA header is a pair of 503 fields that identify the Posture Collector and/or Posture 504 Validator involved in the exchange. These fields are used for 505 performing exclusive delivery of messages as described in 506 section 3.1 and as an indicator for correlation of received 507 attributes. 509 Correlation of attributes is necessary when the sending Posture 510 Collector provides posture for multiple implementations of a 511 single type of component during an assessment, so the recipient 512 Posture Validators need to know which attributes are describing 513 the same implementation. 515 For example, a single Posture Collector might report attributes 516 on two installed VPN implementations on the endpoint. Because 517 the individual attributes do not include an indication of which 518 VPN product they are describing, the recipient needs something 519 to perform this correlation. Therefore, for this example, the 520 VPN Posture Collector would need to obtain two Posture Collector 521 Identifiers from the Posture Broker Client and consistently use 522 one with each of the implementations during an assessment. The 523 VPN Posture Collector would group all the attributes associated 524 with a particular VPN implementation into a single PB-PA message 525 and send the message using the Posture Collector Identifier it 526 designates as going with the particular implementation. This 527 approach allows the recipient to recognize when attributes in 528 future assessment messages also describe the same component 529 implementation. 531 3.4. PA-TNC Messages in PB-TNC 533 As depicted in section 3.2, a PA-TNC message consists of a PA- 534 TNC header followed by a sequence of one or more attributes. 535 The PA-TNC message header (described in section 3.6) and the 536 header for each of the PA-TNC attributes (specified in section 537 4.1) have a fixed type-length-value (TLV) format. Each PA-TNC 538 message MAY contain a mixture of standards-based and vendor- 539 defined attributes identifiable using the type portion of the 540 attribute header. All Posture Collectors and Posture Validators 541 compliant with this specification MUST be capable of processing 542 multiple attributes in a received PA-TNC message. A Posture 543 Collector or Posture Validator that receives a PA-TNC message 544 can use the attribute header's length field to skip any 545 attributes that it does not understand, unless the attribute is 546 marked as mandatory to process. 548 3.5. IETF Standard PA Subtypes 550 This section defines several IETF Standard PA Subtypes. Each PA 551 subtype defined here identifies a specific component relevant to 552 the endpoint's posture. This allows a small set of generic PA- 553 TNC attributes (e.g. Product Information) to be used to describe 554 a large number of different components (e.g. operating system, 555 anti-virus, etc.). It also allows Posture Collectors and 556 Posture Validators to specialize in a particular component and 557 only receive PA-TNC messages relevant to that component. 559 Value Name Definition 560 ----- ---- ---------- 561 0 Testing Reserved for use in specification 562 examples, experimentation and 563 testing. 565 1 Operating System Operating system running on the 566 endpoint 568 2 Anti-Virus Host-based anti-virus software 570 3 Anti-Spyware Host-based anti-spyware software 572 4 Anti-Malware Host-based anti-malware (e.g. anti- 573 bot) software not included within 574 anti-virus or anti-spyware components 576 5 Firewall Host-based firewall 578 6 IDPS Host-based Intrusion Detection and/or 579 Prevention Software (IDPS) 581 7 VPN Host-based Virtual Private Networking 582 (VPN) software 584 8 NEA Client NEA client software 586 These PA subtypes must be used in a PB-PA message with a PA 587 Message Vendor ID of zero (0) indicating an IETF standard type 588 of component (as described in the PB-TNC specification [5]). If 589 these PA subtype values are used with a different PA Message 590 Vendor ID, they have a completely different meaning that is not 591 defined in this specification. Posture Collectors and Posture 592 Validators MUST NOT require support for particular vendor- 593 specific PA subtypes and MUST interoperate with other parties 594 despite any differences in the set of vendor-specific PA 595 subtypes supported (although they MAY permit administrators to 596 configure them to require support for specific PA subtypes). 598 3.6. PA-TNC Message Header Format 600 This section describes the format and semantics of the PA-TNC 601 header. Every PA-TNC message MUST start with a PA-TNC header. 602 The PA-TNC header provides a common context applying to all of 603 the attributes contained within the PA-TNC payload. The payload 604 consists of a sequence of assessment attributes described in 605 section 4.2. 607 1 2 3 608 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 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Version | Reserved | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Message Identifier | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 Version 617 This field indicates the version of the format for the PA-TNC 618 message. This version is intended to allow for evolution of 619 the PA-TNC message header and payload in a manner that can 620 easily be detected by message recipients. 622 PA-TNC message senders MUST set this field to 0x01 for all 623 PA-TNC messages that comply with this specification. 624 Implementations responding to a PA-TNC message containing a 625 supported version MUST use the same Version number to 626 minimize the risk of version incompatibility. Message 627 recipients MUST respond to a PA-TNC message containing an 628 unsupported version by sending a Version Not Supported error 629 in a PA-TNC Error attribute that is the only PA-TNC attribute 630 in a PA-TNC message with version number 1. 632 PA-TNC message initiators supporting multiple PA-TNC protocol 633 versions SHOULD be able to alter which version of PA-TNC 634 message they send based on prior message exchanges with a 635 particular peer Posture Collector or Posture Validator. 637 Reserved 639 Reserved for future use. This field MUST be set to 0 on 640 transmission and ignored upon reception. 642 Message Identifier 643 This field contains a value that uniquely identifies this 644 message, differentiating it from others sent by a particular 645 PA-TNC message sender within this assessment. This value can 646 be included in the payload of a response message to indicate 647 which message was received and caused the response. This 648 value is included in the payload of PA-TNC error messages so 649 the party who receives the error message can determine which 650 of the messages they had sent caused the error. 652 PA-TNC message senders MUST NOT send the same message 653 identifier more than once during an assessment. Message 654 identifiers may be randomly generated or sequenced as long as 655 values are not repeated during an assessment message 656 exchange. PA-TNC message recipients are not required to 657 check for duplicate message identifiers. 659 4. PA-TNC Attributes 661 This section defines the PA-TNC attributes that can be carried 662 within a PA-TNC message. The initial section defines the 663 standard attribute header that appears at the start of each 664 attribute in a PA-TNC message. The second section defines each 665 of the IETF Standard PA-TNC attributes and the final section 666 discusses how vendor-defined PA-TNC attributes can be used 667 within a PA-TNC message. Vendor-defined PA-TNC attributes use 668 the vendor's SMI Private Enterprise Number in the Attribute Type 669 field. 671 A PA-TNC message MUST contain a PA-TNC header (defined in 672 section 3.6. followed by a sequence of zero or more PA-TNC 673 attributes. All PA-TNC attributes MUST begin with a standard 674 PA-TNC attribute header, as defined in section 4.1. The 675 contents of PA-TNC attributes vary widely, depending on their 676 attribute type. Section 4.2 defines the IETF Standard PA-TNC 677 Attributes. Section 4.3 discusses how vendor-specific PA-TNC 678 attributes can be defined. 680 4.1. PA-TNC Attribute Header 682 Following the PA-TNC message header is a sequence of zero or 683 more attributes. All PA-TNC attributes MUST begin with the 684 standard PA-TNC attribute header defined in this subsection. 685 Each attribute described in this specification is represented by 686 a TLV tuple. The TLV tuple includes an attribute identifier 687 comprised of the Vendor ID and Attribute Type (type), the TLV 688 tuple's overall length and finally the attribute's value. The 689 use of TLV representation was chosen due to its flexibility and 690 extensibility and use in other standards. Recipients of an 691 attribute can use the attribute type fields to determine the 692 precise syntax and semantics of the attribute value field and 693 the length to skip over an unrecognized attribute. The length 694 field is also beneficial when a variable length attribute value 695 is provided. 697 The TLV format does not contain an explicit TLV format version 698 number, so every attribute included in a particular PA-TNC 699 message MUST use the same TLV format. Using the PA-TNC message 700 version number to indicate the format of all TLV attributes 701 within a PA-TNC message allows for future versioning of the TLV 702 format in a manner detectable by PA-TNC message recipients. 703 Similarly, requiring all TLV attribute formats to be the same 704 within a PA-TNC message also assures that recipients compliant 705 with a particular PA-TNC message version can at least parse 706 every attribute header and use the length to skip over 707 unrecognized attributes. Finally all attribute TLVs within a 708 PA-TNC message MUST pertain to the same implementation of the 709 component. This restriction is relevant when a single Posture 710 Collector is reporting on multiple implementations of a 711 component, so must send multiple PA-TNC messages each including 712 only the attributes describing a single implementation. For 713 more information on how Posture Collectors should handle 714 multiple implementations see section 3.3. 716 Every PA-TNC compliant TLV attribute MUST use the following TLV 717 format: 719 1 2 3 720 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 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Flags | PA-TNC Attribute Vendor ID | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | PA-TNC Attribute Type | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | PA-TNC Attribute Length | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | Attribute Value (Variable Length) | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 Flags 733 This field defines flags impacting the processing of the 734 associated attribute. 736 Bit 0 (0x80) is the NOSKIP flag. Any Posture Collector or 737 Posture Validator that receives an attribute with this flag 738 set to 1 but does not support this attribute MUST NOT process 739 any part of the PA-TNC message and SHOULD respond with an 740 Attribute Type Not Supported error in a PA-TNC error message. 742 In order to avoid taking action on a subset of the attributes 743 only to later find an unsupported attribute with the NOSKIP 744 flag set, recipients of a multi-attribute PA-TNC message 745 might need to scan all of the attributes prior to acting upon 746 any attribute. 748 When the NOSKIP flag is set to 0, recipients SHOULD skip any 749 unsupported attributes and continue processing the next 750 attribute. 752 Bit 1-7 are reserved for future use. These bits MUST be set 753 to 0 on transmission and ignored upon reception. 755 PA-TNC Attribute Vendor ID 757 This field indicates the owner of the name space associated 758 with the PA-TNC Attribute Type. This is accomplished by 759 specifying the 24 bit SMI Private Enterprise Number Vendor ID 760 of the party who owns the Attribute Type name space. IETF 761 Standard PA-TNC Attribute Types MUST use zero (0) in this 762 field. 764 The PA-TNC Attribute Vendor ID 0xffffff is reserved. Posture 765 Collectors and Posture Validators MUST NOT send PA-TNC 766 messages in which the PA-TNC Attribute Vendor ID has this 767 reserved value (0xffffff). If a Posture Collector or Posture 768 Validator receives a message in which the PA-TNC Attribute 769 Vendor ID has this reserved value (0xffffff), it SHOULD 770 respond with an Invalid Parameter error code in a PA-TNC 771 Error attribute. 773 PA-TNC Attribute Type 775 This field defines the type of the attribute included in the 776 Attribute Value field. This field is qualified by the PA-TNC 777 Attribute Vendor ID field so that a particular PA-TNC 778 Attribute Type value (e.g. 327) has a completely different 779 meaning depending on the value in the PA-TNC Attribute Vendor 780 ID field. Posture Collectors and Posture Validators MUST NOT 781 require support for particular vendor-specific PA-TNC 782 Attribute Types and MUST interoperate with other parties 783 despite any differences in the set of vendor-specific PA-TNC 784 Attribute Types supported (although they MAY permit 785 administrators to configure them to require support for 786 specific PA-TNC attribute types). 788 If the PA-TNC Attribute Vendor ID field has the value zero 789 (0) then the PA-TNC Attribute Type field contains an IETF 790 Standard PA-TNC Attribute Type, as listed in the IANA 791 registry. IANA maintains a registry of PA-TNC Attribute 792 Types. Entries in this registry are added by Expert Review 793 with Specification Required, following the guidelines in 794 section 7. Section 4.2 of this specification defines the 795 initial set of IETF Standard PA-TNC Attribute Types. 797 The PA-TNC Attribute Type 0xffffffff is reserved. Posture 798 Collectors and Posture Validators MUST NOT send PA-TNC 799 messages in which the PA-TNC Attribute Type has this reserved 800 value (0xffffffff). If a Posture Collector or Posture 801 Validator receives a message in which the PA-TNC Attribute 802 Type has this reserved value (0xffffffff), it SHOULD respond 803 with an Invalid Parameter error code in a PA-TNC Error 804 attribute. 806 PA-TNC Attribute Length 808 This field contains the length in octets of the entire PA-TNC 809 Attribute including the PA-TNC Attribute Header (the fields 810 Flags, PA-TNC Attribute Vendor ID, PA-TNC Attribute Type, and 811 PA-TNC Attribute Length). Therefore, this value MUST always 812 be at least 12. Any Posture Collector or Posture Validator 813 that receives a message with a PA-TNC Attribute Length field 814 whose value is less than 12 SHOULD respond with an Invalid 815 Parameter PA-TNC error code. Similarly, if a Posture 816 Collector or Posture Validator receives a PA-TNC message for 817 an Attribute Type that has a well known Attribute Value 818 length (e.g. fixed length attribute value) and the Attribute 819 Length indicates a different value (greater or less than the 820 expected value), the recipient SHOULD respond with an Invalid 821 Parameter PA-TNC error code. 823 Implementations that do not support the specified PA-TNC 824 Attribute Type can use this length to skip over this 825 attribute to the next attribute. Note that while this field 826 is 4 octets the maximum usable attribute length is less than 827 2^32-1 due to limitations of the underlying protocol stack. 828 Specifically PB-TNC TLV header's Batch Length field is also 829 32 bits in length. Therefore the maximum batch that PB-TNC 830 can carry is 2^32-1, so the largest PA-TNC message carried by 831 PB-TNC must be less than 2^32-1 - size of the PB-TNC header 832 (see section 4.1 of PB-TNC for more details). 834 Attribute Value 836 This field varies depending on the particular type of 837 attribute being expressed. The contents of this field for 838 each of the IETF Standard PA-TNC Attribute Types are defined 839 in section 4.2. 841 4.2. IETF Standard PA-TNC Attribute Types 843 This section defines an initial set of IETF Standard PA-TNC 844 Attribute Types. These Attribute Types MUST always be used with 845 a PA-TNC Vendor ID of zero (0). If these PA-TNC Attribute Type 846 values are used with a different PA-TNC Vendor ID, they have a 847 completely different meaning that is not defined in this 848 specification. 850 The following table briefly describes each attribute and defines 851 the numeric value to be used in the PA-TNC Attribute Type field 852 of the PA-TNC Attribute Header. Later subsections provide 853 detailed specifications for each PA-TNC Attribute Value. 855 Number Name Description 856 ------ ---- ----------- 857 0 Testing Reserved for use in 858 specification examples, 859 experimentation and testing. 861 1 Attribute Request Contains a list of attribute 862 type values defining the 863 attributes desired from the 864 Posture Collectors. 866 2 Product Information Manufacturer and product 867 information for the component. 869 3 Numeric Version Numeric version of the 870 component. 872 4 String Version String version of the 873 component. 875 5 Operational Status Describes whether the component 876 is running on the endpoint. 878 6 Port Filter Lists the set of ports (e.g. 879 TCP port 80 for HTTP) that are 880 allowed or blocked on the 881 endpoint. 883 7 Installed Packages List of software packages 884 installed on endpoint that 885 provide the requested 886 component. 888 8 PA-TNC Error PA-TNC message or attribute 889 processing error. 891 9 Assessment Result Result of the assessment 892 performed by a Posture 893 Validator. 895 10 Remediation Instructions Instructions for remediation 896 generated by a Posture 897 Validator. 899 11 Forwarding Enabled Indicates whether packet 900 forwarding has been enabled 901 between different interfaces on 902 the endpoint. 904 12 Factory Default Password Indicates whether the endpoint 905 has a factory default password 906 enabled. 908 The following subsections discuss the usage, format and semantics 909 of the Attribute Value field for each IETF Standard PA-TNC 910 Attribute Type. 912 4.2.1. Attribute Request 914 This PA-TNC Attribute Type allows a Posture Validator to request 915 certain attributes from the registered set of Posture 916 Collectors. 918 All Posture Collectors that implement any of the IETF Standard 919 PA Subtypes defined in this specification SHOULD support 920 receiving and processing this attribute type for at least those 921 PA subtypes. This requirement is only a "should" because there 922 are deployment scenarios (e.g. see section A.1) where the 923 Posture Collectors proactively sends a set of attributes at the 924 start of an assessment (e.g. based upon local policy), so does 925 not need to support Posture Validator requested attributes. 926 Posture Collectors that receive but do not support the Attribute 927 Request attribute MUST respond with an Attribute Type Not 928 Supported PA-TNC error code. Posture Collectors that receive 929 and process this attribute MAY choose to send all, a subset or 930 none of the requested attributes but MUST NOT send attributes 931 that were not requested (except error attributes). All Posture 932 Validators that implement any of the IETF Standard PA Subtypes 933 defined in this specification SHOULD support sending this 934 attribute type for at least those PA subtypes. 936 Posture Validators MUST NOT include this attribute type in an 937 Attribute Request attribute. It does not make sense for a 938 Posture Validator to request that a Posture Collector send an 939 Attribute Request attribute. 941 For this attribute type, the PA-TNC Attribute Vendor ID field 942 MUST be set to zero (0) and the PA-TNC Attribute Type field MUST 943 be set to 1. 945 The following diagram illustrates the format and contents of the 946 Attribute Value field for this attribute type. The text after 947 this diagram describes the fields shown here. 949 Note that this diagram shows two attribute types. The actual 950 number of attribute types included in an Attribute Request 951 attribute can vary from one to a large number (limited only by 952 the maximum message and length supported by the underlying PT 953 transport protocol). However, each Attribute Request MUST 954 contain at least one attribute type. Because the length of a 955 PA-TNC Attribute Vendor ID paired with a PA-TNC Attribute Type 956 and a one octet Reserved field is always 8 octets, the number of 957 requested attributes can be easily computed using the PA-TNC 958 Attribute Length field by subtracting the number of octets in 959 the PA-TNC Attribute Header and dividing by 8. If the PA-TNC 960 Attribute Length field is invalid, Posture Collectors SHOULD 961 respond with an Invalid Parameter PA-TNC error code. 963 1 2 3 964 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 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | Reserved | PA-TNC Attribute Vendor ID | 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 | PA-TNC Attribute Type | 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 | Reserved | PA-TNC Attribute Vendor ID | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | PA-TNC Attribute Type | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 Reserved 977 Reserved for future use. This field MUST be set to 0 on 978 transmission and ignored upon reception. 980 PA-TNC Attribute Vendor ID 982 This field contains the SMI Private Enterprise Number of the 983 organization that controls the name space for the following 984 PA-TNC Attribute Type. This field enables IETF Standard PA- 985 TNC Attributes and vendor-defined PA-TNC Attributes to be 986 used without potential collisions. 988 Any IETF Standard PA-TNC Attribute Types defined in section 989 4.2 MUST use zero (0) in this field. Vendor-defined 990 attributes MUST use the SMI Private Enterprise Number of the 991 organization that defined the attribute. 993 PA-TNC Attribute Type 995 The PA-TNC Attribute Type field (together with the PA-TNC 996 Vendor ID field) indicates the specific attribute requested. 997 Some IETF Standard PA-TNC Attribute Types MUST NOT be 998 requested using this field (e.g. requesting a PA-TNC Error 999 attribute). This is explicitly indicated in the description 1000 of those PA-TNC Attribute Types. Any Posture Collector or 1001 Posture Validator that receives an Attribute Request 1002 containing one of the prohibited Attribute Types SHOULD 1003 respond with an Invalid Parameter error in a PA-TNC error 1004 message. 1006 4.2.2. Product Information 1008 This PA-TNC Attribute Type contains identifying information 1009 about a product that implements the component specified in the 1010 PA Subtype field, as described in section 3.5. For example, if 1011 the PA Subtype is Anti-Virus, this attribute would contain 1012 information identifying an anti-virus product installed on the 1013 endpoint. 1015 All Posture Collectors that implement any of the IETF Standard 1016 PA Subtypes defined in this specification MUST support sending 1017 this attribute type, at least for those PA subtypes. Whether a 1018 particular Posture Collector actually sends this attribute type 1019 SHOULD still be governed by local privacy and security policies. 1020 All Posture Validators that implement any of the IETF Standard 1021 PA Subtypes defined in this specification MUST support receiving 1022 this attribute type, at least for those PA subtypes. Posture 1023 Validators MUST NOT send this attribute type. 1025 For this attribute type, the PA-TNC Attribute Vendor ID field 1026 MUST be set to zero (0) and the PA-TNC Attribute Type field MUST 1027 be set to 2. The value in the PA-TNC Attribute Length field 1028 will vary, depending on the length of the Product Name field. 1029 However, the value in the PA-TNC Attribute Length field MUST be 1030 at least 17 because this is the length of the fixed size fields 1031 in the PA-TNC Attribute Header and the fixed size fields in this 1032 attribute type. If the PA-TNC Attribute Length field is less 1033 than the size of these fixed length fields, implementations 1034 SHOULD respond with an Invalid Parameter PA-TNC error code. 1036 This attribute type includes both numeric and textual 1037 identifiers for the organization that created the product (the 1038 "product creator") and for the product itself. For automated 1039 processing, numeric identifiers are superior because they are 1040 less ambiguous and more efficient. However, numeric identifiers 1041 are only available if the product creator has assigned them. 1042 Therefore, a textual identifier is also included. This textual 1043 identifier has the additional benefit that it may be easier for 1044 humans to read (although this benefit is minimal since the 1045 primary purpose of this attribute is automated assessment). 1047 The following diagram illustrates the format and contents of the 1048 Attribute Value field for this attribute type. The text after 1049 this diagram describes the fields shown here. 1051 1 2 3 1052 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 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 | Product Vendor ID | Product ID | 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 | Product ID | Product Name (Variable Length) | 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 Product Vendor ID 1061 This field contains the SMI Private Enterprise Number for the 1062 product creator. If the SMI PEN for the product creator is 1063 unknown or if the product creator does not have an SMI PEN, 1064 the Product Vendor ID field MUST be set to 0 and the identity 1065 of the product creator SHOULD be included in the Product Name 1066 along with the name of the product. 1068 Product ID 1070 This field identifies the product using a numeric identifier 1071 assigned by the product creator. If this Product ID value is 1072 unknown or if the product creator has not assigned such a 1073 value, this field MUST be set to 0. If the Product Vendor ID 1074 is 0, this field MUST be set to 0. In any case, the name of 1075 the product SHOULD be included in the Product Name field. 1077 Note that a particular Product ID value (e.g. 635) will have 1078 completely different meanings depending on the Product Vendor 1079 ID. Each Product Vendor ID defines a different space of 1080 Product ID values. Product creators are encouraged to 1081 publish lists of Product ID values for their products. 1083 Product Name 1085 This variable length field contains a UTF-8 [2] string 1086 identifying the product (e.g. "Symantec Norton AntiVirus(TM) 1087 2008") in enough detail to unambiguously distinguish it from 1088 other products from the product creator. Products whose 1089 creator is known, but does not have a registered SMI Private 1090 Enterprise Number, SHOULD be represented using a combination 1091 of the creator name and full product name (e.g. "Ubuntu(R) 1092 IPtables" for the IPtables firewall in the Ubuntu 1093 distribution of Linux). If the product creator's SMI Private 1094 Enterprise Number is included in the Product Vendor ID field, 1095 the product creator's name may be omitted from this field. 1097 The length of this field can be determined by starting with 1098 the value in the PA-TNC Attribute Length field in the PA-TNC 1099 Attribute Header and subtracting the size of the fixed length 1100 fields in that header (12) and the size of the fixed length 1101 fields in this attribute (5). If the PA-TNC Attribute Length 1102 field is less than the size of these fixed length fields, 1103 implementations SHOULD respond with an Invalid Parameter PA- 1104 TNC error code. 1106 4.2.3. Numeric Version 1108 This PA-TNC Attribute Type contains numeric version information 1109 for a product on the endpoint that implements the component 1110 specified in the PA Subtype field, as described in section 3.5. 1111 For example, if the PA Subtype is Operating System, this 1112 attribute would contain numeric version information for the 1113 operating system installed on the endpoint. The version 1114 information in this attribute is associated with a particular 1115 product, so Posture Validators are expected to also possess the 1116 corresponding Product Information attribute when interpreting 1117 this attribute. 1119 All Posture Collectors that implement the IETF Standard PA 1120 Subtype for Operating System SHOULD support sending this 1121 attribute type, at least for the Operating System PA subtype. 1122 Other Posture Collectors MAY support sending this attribute 1123 type. Whether a particular Posture Collector actually sends 1124 this attribute type SHOULD still be governed by local privacy 1125 and security policies. All Posture Validators that implement 1126 the IETF Standard PA Subtype for Operating System SHOULD support 1127 receiving this attribute type, at least for the Operating System 1128 PA subtype. Other Posture Validators MAY support receiving this 1129 attribute type. A Posture Validator that does not support 1130 receiving this attribute type SHOULD simply ignore attributes 1131 with this type. Posture Validators MUST NOT send this attribute 1132 type. 1134 For this attribute type, the PA-TNC Attribute Vendor ID field 1135 MUST be set to zero (0) and the PA-TNC Attribute Type field MUST 1136 be set to 3. The value in the PA-TNC Attribute Length field 1137 MUST be 28. If the PA-TNC Attribute Length field is less than 1138 the size of these fixed length fields, implementations SHOULD 1139 respond with an Invalid Parameter PA-TNC error code. 1141 This attribute type includes numeric values for the product 1142 version information, enabling Posture Validators to do 1143 comparative operations on the version. Some Posture Collectors 1144 may not be able to determine some or all of this information for 1145 a product. However, this attribute can be especially useful for 1146 describing the version of the operating system, where numeric 1147 version numbers are generally available. 1149 The following diagram illustrates the format and contents of the 1150 Attribute Value field for this attribute type. The text after 1151 this diagram describes the fields shown here. 1153 1 2 3 1154 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 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 | Major Version Number | 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 | Minor Version Number | 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 | Build Number | 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 | Service Pack Major | Service Pack Minor | 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 Major Version Number 1167 This field contains the major version number for the product, 1168 if applicable. If unused or unknown, this field SHOULD be set 1169 to 0. 1171 Minor Version Number 1173 This field contains the minor version number for the product, 1174 if applicable. If unused or unknown, this field SHOULD be set 1175 to 0. 1177 Build Number 1179 This field contains the build number for the product, if 1180 applicable. This may provide more granularity than the minor 1181 version number, as many builds may occur leading up to an 1182 official release, and all these builds may share a single 1183 major and minor version number. If unused or unknown, this 1184 field SHOULD be set to 0. 1186 Service Pack Major 1188 This field contains the major version number of the service 1189 pack for the product, if applicable. If unused or unknown, 1190 this field SHOULD be set to 0. 1192 Service Pack Minor 1194 This field contains the minor version number of the service 1195 pack for the product, if applicable. If unused or unknown, 1196 this field SHOULD be set to 0. 1198 4.2.4. String Version 1200 This PA-TNC Attribute Type contains string version information 1201 for a product on the endpoint that implements the component 1202 specified in the PA Subtype field, as described in section 3.5. 1203 For example, if the PA Subtype is Firewall, this attribute would 1204 contain string version information for a host-based firewall 1205 product installed on the endpoint (if any). The version 1206 information in this attribute is associated with a particular 1207 product, so Posture Validators are expected to also possess the 1208 corresponding Product Information attribute when interpreting 1209 this attribute. 1211 All Posture Collectors that implement any of the IETF Standard 1212 PA Subtypes defined in this document MUST support sending this 1213 attribute type, at least for those PA subtypes. Other Posture 1214 Collectors MAY support sending this attribute type. Whether a 1215 particular Posture Collector actually sends this attribute type 1216 SHOULD still be governed by local privacy and security policies. 1217 All Posture Validators that implement any of the IETF Standard 1218 PA Subtypes defined in this document MUST support receiving this 1219 attribute type, at least for those PA subtypes. Other Posture 1220 Validators MAY support receiving this attribute type. Posture 1221 Validators MUST NOT send this attribute type. 1223 For this attribute type, the PA-TNC Attribute Vendor ID field 1224 MUST be set to zero (0) and the PA-TNC Attribute Type field MUST 1225 be set to 4. The value in the PA-TNC Attribute Length field 1226 will vary, depending on the length of the Component Version 1227 Number, Internal Build Number, and Configuration Version Number 1228 fields. However, the value in the PA-TNC Attribute Length field 1229 MUST be at least 15 because this is the length of the fixed size 1230 fields in the PA-TNC Attribute Header and the fixed size fields 1231 in this attribute type. If the PA-TNC Attribute Length field is 1232 less than the size of these fixed length fields or does not 1233 match the length indicated by the sum of the fixed length and 1234 variable length fields, implementations SHOULD respond with an 1235 Invalid Parameter PA-TNC error code. 1237 The following diagram illustrates the format and contents of the 1238 Attribute Value field for this attribute type. The text after 1239 this diagram describes the fields shown here. 1241 1 2 3 1242 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 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1244 | Version Len | Product Version Number (Variable Length) | 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 | Build Num Len | Internal Build Number (Variable Length) | 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1248 | Config. Len | Configuration Version Number (Variable Length)| 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 Version Len 1253 This field defines the number of octets in the Product 1254 Version Number field. If the product version number is 1255 unavailable or unknown, this field MUST be set to 0 and the 1256 Product Version Number field will be zero length (effectively 1257 not present). 1259 Product Version Number 1261 This field contains a UTF-8 string identifying the version of 1262 the component (e.g. "1.12.23.114"). This field MUST be sized 1263 to fit the version string and MUST NOT include extra octets 1264 for padding or NUL character termination. 1266 Various products use a wide range of different formats and 1267 semantics for version strings. Some use alphabetic 1268 characters, white space, and punctuation. Some consider 1269 version "1.21" to be later than version "1.3" and some 1270 earlier. Therefore, the syntax and semantics of this string 1271 are not defined. 1273 Build Num Len 1275 This field defines the number of octets in the Internal Build 1276 Number field. For products where the internal build number 1277 is unavailable or unknown, this field MUST be set to 0 and 1278 the Internal Build Number field will be zero length 1279 (effectively not present). 1281 Internal Build Number 1282 This field contains a UTF-8 string identifying the 1283 engineering build number of the product. This field MUST be 1284 sized to fit the build number string and MUST NOT include 1285 extra octets for padding or NUL character termination. The 1286 syntax and semantics of this string are not defined. 1288 Config. Len 1290 This field defines the number of octets in the Configuration 1291 Version Number field. If the configuration version number is 1292 unavailable or unknown, this field MUST be set to 0 and the 1293 Configuration Version Number field will be zero length 1294 (effectively not present). 1296 Configuration Version Number 1298 This field contains a UTF-8 string identifying the version of 1299 the configuration used by the component. This version SHOULD 1300 represent the overall configuration version even if several 1301 configuration policy files or settings are used. Posture 1302 Collectors MAY include multiple version numbers in this 1303 single string if a single version is not practical. This 1304 field MUST be sized to fit the version string and MUST NOT 1305 include extra octets for padding or NUL character 1306 termination. 1308 Various products use a wide range of different formats for 1309 version strings. Some use alphabetic characters, white 1310 space, and punctuation. Some consider version "1.21" to be 1311 later than version "1.3" and some earlier. In addition, some 1312 Posture Collectors may place multiple configuration version 1313 numbers in this single string. Therefore, the syntax and 1314 semantics of this string are not defined. 1316 4.2.5. Operational Status 1318 This PA-TNC Attribute Type describes the operational status of a 1319 product that can implement the component specified in the PA 1320 Subtype field, as described in section 3.5. For example, if the 1321 PA Subtype is Anti-Spyware, this attribute would contain 1322 information about the operational status of a host-based anti- 1323 spyware product that may or may not be installed on the 1324 endpoint. 1326 Posture Collectors that implement the IETF Standard PA Subtype 1327 for Operating System or VPN MAY support sending this attribute 1328 type for those PA subtypes. Posture Collectors that implement 1329 other IETF Standard PA Subtypes defined in this specification 1330 SHOULD support sending this attribute type for those PA 1331 subtypes. Other Posture Collectors MAY support sending this 1332 attribute type. Whether a particular Posture Collector actually 1333 sends this attribute type SHOULD still be governed by local 1334 privacy and security policies. Posture Validators that 1335 implement the IETF Standard PA Subtype for Operating System or 1336 VPN MAY support receiving this attribute type, at least for 1337 those PA subtypes. Posture Validators that implement other IETF 1338 Standard PA Subtypes defined in this specification SHOULD 1339 support receiving this attribute type, at least for those PA 1340 subtypes. Other Posture Validators MAY support receiving this 1341 attribute type. A Posture Validator that does not support 1342 receiving this attribute type SHOULD simply ignore attributes 1343 with this type. Posture Validators MUST NOT send this attribute 1344 type. 1346 For this attribute type, the PA-TNC Attribute Vendor ID field 1347 MUST be set to zero (0) and the PA-TNC Attribute Type field MUST 1348 be set to 5. The value in the PA-TNC Attribute Length field 1349 MUST be 36. If the PA-TNC Attribute Length field does not have 1350 this value, implementations SHOULD respond with an Invalid 1351 Parameter PA-TNC error code. 1353 The following diagram illustrates the format and contents of the 1354 Attribute Value field for this attribute type. The text after 1355 this diagram describes the fields shown here. 1357 1 2 3 1358 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 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1360 | Status | Result | Reserved | 1361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1362 | Last Use | 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1364 | Last Use (continued) | 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 | Last Use (continued) | 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 | Last Use (continued) | 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 | Last Use (continued) | 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 Status 1374 This field gives the operational status of the product. The 1375 following table lists the values currently defined for this 1376 field. 1378 Value Description 1379 ----- ----------- 1380 0 Unknown or other 1381 1 Not installed 1382 2 Installed but not operational 1383 3 Operational 1385 If a Posture Validator receives a value for this field that 1386 it does not recognize, it SHOULD treat this value as 1387 equivalent to the value 0. 1389 Result 1391 This field contains the result of the last use of the 1392 product. The following table lists the values currently 1393 defined for this field. 1395 Value Description 1396 ----- ----------- 1397 0 Unknown or other 1398 1 Successful use with no errors detected 1399 2 Successful use with one or more errors detected 1400 3 Unsuccessful use (e.g. aborted) 1402 Posture Collectors SHOULD set this field to 0 if the Status 1403 field contains a value of 1 (Not installed) or 2 (Installed 1404 but not operational). If a Posture Validator receives a 1405 value for this field that it does not recognize, it SHOULD 1406 treat this value as equivalent to the value 0. 1408 Reserved 1410 This field is reserved for future use. The field MUST be set 1411 to 0 on transmission and ignored upon reception. 1413 Last Use 1415 This field contains the date and time of the last use of the 1416 component. The Last Use date and time MUST be represented as 1417 an RFC 3339 [4] compliant ASCII string in Coordinated 1418 Universal Time (UTC) time with the additional restrictions 1419 that the 't' delimiter and the 'z' suffix MUST be capitalized 1420 and fractional seconds (time-secfrac) MUST NOT be included. 1422 This field conforms to the date-time ABNF production from 1423 section 5.6 of RFC 3339 with the above restrictions. Leap 1424 seconds are permitted and Posture Validators MUST support 1425 them. 1427 The last use string MUST NOT be NUL terminated or padded in 1428 any way. If the last use time is not known, not applicable, 1429 or cannot be represented in this format, the Posture 1430 Collector MUST set this field to the value "0000-00- 1431 00T00:00:00Z" (allowing this field to be fixed length). Note 1432 that this particular reserved value is NOT a valid RFC 3339 1433 date and time and MUST NOT be used for any other purpose in 1434 this field. 1436 This encoding produces a string that is easy to read, parse, 1437 and interpret. The format (more precisely defined in RFC 1438 3339) is YYYY-MM-DDTHH:MM:SSZ, resulting in one and only one 1439 representation for each second in UTC time from year 0000 to 1440 year 9999. For example, 9:05:00AM EST (GMT-0500) on January 1441 19, 1995 can be represented as "1995-01-19T14:05:00Z". The 1442 length of this field is always 20 octets. 1444 4.2.6. Port Filter 1446 This PA-TNC Attribute Type provides the list of port numbers and 1447 associated protocols (e.g. TCP and UDP) that are currently 1448 blocked or allowed by a host-based firewall on the endpoint. 1450 Posture Collectors that implement the IETF Standard PA Subtype 1451 for Firewall or VPN SHOULD support sending this attribute type 1452 for those PA subtypes. Posture Collectors that implement other 1453 IETF Standard PA Subtypes defined in this specification MUST NOT 1454 support sending this attribute type for those PA subtypes. 1455 Other Posture Collectors MAY support sending this attribute 1456 type, if it is appropriate to their PA subtype. Whether a 1457 particular Posture Collector actually sends this attribute type 1458 SHOULD still be governed by local privacy and security policies. 1459 Posture Validators that implement the IETF Standard PA Subtype 1460 for Firewall or VPN SHOULD support receiving this attribute 1461 type, at least for those PA subtypes. Posture Validators that 1462 implement other IETF Standard PA Subtypes defined in this 1463 specification MUST NOT support receiving this attribute type for 1464 those PA subtypes. Other Posture Validators MAY support 1465 receiving this attribute type. A Posture Validator that does 1466 not support receiving this attribute type SHOULD simply ignore 1467 attributes with this type. Posture Validators MUST NOT send 1468 this attribute type. 1470 For this attribute type, the PA-TNC Attribute Vendor ID field 1471 MUST be set to zero (0) and the PA-TNC Attribute Type field MUST 1472 be set to 6. 1474 The following diagram illustrates the format and contents of the 1475 Attribute Value field for this attribute type. The text after 1476 this diagram describes the fields shown here. 1478 Note that this diagram shows two Protocol/Port Number pairs. The 1479 actual number of Protocol/Port Number pairs included in a Port 1480 Filter attribute can vary from one to a large number (limited 1481 only by the maximum message and length supported by the 1482 underlying PT transport protocol). However, each Port Filter 1483 attribute MUST contain at least one Protocol/Port Number pair. 1484 Because the length of a Protocol/Port Number pair with the 1485 Reserved field and B flag is always 4 octets, the number of 1486 Protocol/Port Number pairs can be easily computed using the PA- 1487 TNC Attribute Length field by subtracting the number of octets 1488 in the PA-TNC Attribute Header and dividing by 4. If the PA-TNC 1489 Attribute Length field is invalid, Posture Validators SHOULD 1490 respond with an Invalid Parameter PA-TNC error code. 1492 1 2 3 1493 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 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 | Reserved |B| Protocol | Port Number | 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1497 | Reserved |B| Protocol | Port Number | 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 Reserved 1502 This field is reserved for future use. It MUST be set to 0 1503 on transmission and ignored upon reception. 1505 B Flag (Blocked or Allowed Port) 1507 This single bit field indicates whether the following port is 1508 blocked or allowed. This bit MUST be set to 1 if the 1509 protocol and port combination is blocked. Otherwise this 1510 field MUST be set to 0. This field was provided to allow for 1511 more abbreviated reporting of the port filtering policy (e.g. 1512 when all ports are blocked except a few, the Posture 1513 Collector can just list the few that are allowed). 1515 Posture Collectors MUST NOT provide a mixed list of block and 1516 non-blocked ports for a particular protocol. To be more 1517 precise, a Posture Collector MUST NOT include two 1518 Protocol/Port Number pairs in a single Port Filter attribute 1519 where the protocol number is the same but the B flag is 1520 different. Also, Posture Collectors MUST NOT list the same 1521 Protocol and Port Number combination twice in a Port List 1522 attribute. 1524 Posture Collectors MAY list all blocked ports for one 1525 protocol and all allowed ports for a different protocol in a 1526 single Port List attribute, using the B flag to indicate 1527 whether each entry is blocked. For example, a Posture 1528 Collector might list all the blocked TCP ports but only list 1529 the allowed UDP ports. However it MUST NOT list some blocked 1530 TCP ports and some other allowed TCP ports. 1532 Protocol 1534 This field contains the transport protocol number (e.g. tcp 1535 is 6) being blocked or allowed. The values used in this field 1536 are the same ones used in the IPv4 Protocol and IPv6 Next 1537 Header fields. The IANA already maintains the Assigned 1538 Internet Protocol Numbers registry of these values for use in 1539 this field. 1541 Port Number 1543 This field contains the transport protocol (e.g. tcp) port 1544 number being blocked or allowed. The values used in this 1545 field are specific to the protocol identified by the Protocol 1546 field. The IANA maintains registries for well known and user 1547 requested TCP and UDP port numbers for use in this field. 1549 4.2.7. Installed Packages 1551 This PA-TNC Attribute Type contains a list of the installed 1552 packages that comprise a product on the endpoint that implements 1553 the component specified in the PA Subtype field, as described in 1554 section 3.5. This allows a Posture Validator to check which 1555 packages are installed for a particular product and which 1556 versions of those packages are installed. 1558 Posture Collectors that implement any of the IETF Standard PA 1559 Subtypes defined in this document SHOULD support sending this 1560 attribute type for those PA subtypes. Other Posture Collectors 1561 MAY support sending this attribute type, if it is appropriate to 1562 their PA subtype. Whether a particular Posture Collector 1563 actually sends this attribute type SHOULD still be governed by 1564 local privacy and security policies. Posture Validators that 1565 implement any of the IETF Standard PA Subtypes defined in this 1566 document SHOULD support receiving this attribute type, at least 1567 for those PA subtypes. Other Posture Validators MAY support 1568 receiving this attribute type. A Posture Validator that does 1569 not support receiving this attribute type SHOULD simply ignore 1570 attributes with this type. Posture Validators MUST NOT send 1571 this attribute type. 1573 This attribute type can be quite long, especially for the 1574 Operating System PA subtype. This can cause problems, especially 1575 with 802.1X and other limited transport protocols. Therefore, 1576 Posture Collectors SHOULD NOT send this attribute unless 1577 specifically requested to do so using the Attribute Request 1578 attribute or otherwise configured to do so. Also, Posture 1579 Validators SHOULD NOT request this attribute unless the 1580 transport protocol in use can support the large amount of data 1581 that may be sent in response. 1583 For this attribute type, the PA-TNC Attribute Vendor ID field 1584 MUST be set to zero (0) and the PA-TNC Attribute Type field MUST 1585 be set to 7. The value in the PA-TNC Attribute Length field 1586 will vary, depending on the number of packages and the length of 1587 the Package Name and Package Version Number fields for those 1588 packages. However, the value in the PA-TNC Attribute Length 1589 field MUST be at least 16 because this is the length of the 1590 fixed size fields in the PA-TNC Attribute Header and the fixed 1591 size fields in this attribute type. If the PA-TNC Attribute 1592 Length field is less than the size of these fixed length fields 1593 or does not match the length indicated by the sum of the fixed 1594 length and variable length fields, implementations SHOULD 1595 respond with an Invalid Parameter PA-TNC error code. 1597 The following diagram illustrates the format and contents of the 1598 Attribute Value field for this attribute type. The text after 1599 this diagram describes the fields shown here. 1601 Note that this diagram shows an attribute containing information 1602 on one package. The actual number of package descriptions 1603 included in an Installed Packages attribute is indicated by the 1604 Package Count field. This value may vary from zero to a large 1605 number (up to 65535, if the underlying PT transport protocol can 1606 support that many). If this number is not sufficient, 1607 specialized patch management software should be employed which 1608 can simply report compliance with a pre-established patch 1609 policy. 1611 1 2 3 1612 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 1613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1614 | Reserved | Package Count | 1615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 | Pkg Name Len | Package Name (Variable Length) | 1617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 | Version Len | Package Version Number (Variable Length) | 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 Reserved 1623 This field is reserved for future use. The field MUST be set 1624 to 0 on transmission and ignored upon reception. 1626 Package Count 1628 This field is an unsigned 16-bit integer that indicates the 1629 number of packages listed in this attribute. For each 1630 package so indicated, a Pkg Name Len, Package Name, Version 1631 Len, and Package Version Number field is included in the 1632 attribute. 1634 Pkg Name Len 1636 This field is an unsigned 8-bit integer that indicates the 1637 length of the Package Name field in octets. This field may be 1638 zero if a Package Name is not available. 1640 Package Name 1642 This field contains the name of the package associated with 1643 the product. This field is a UTF-8 encoded character string 1644 whose octet length is given by the Pkg Name Len field. This 1645 field MUST NOT include extra octets for padding or NUL 1646 character termination. The syntax and semantics of this name 1647 are not specified in this document, since they may vary 1648 across products and/or operating systems. Posture Collectors 1649 MAY list two packages with the same name in a single 1650 Installed Packages attribute. The meaning of doing so is not 1651 defined here. 1653 Version Len 1655 This field is an unsigned 8-bit integer that indicates the 1656 length of the Package Version Number field in octets. This 1657 field may be zero if a Package Version Number is not 1658 available. 1660 Package Version Number 1662 This field contains the version string for the package named 1663 in the previous Package Name field. This field is a UTF-8 1664 encoded character string whose octet length is given by the 1665 Version Len field. This field MUST NOT include extra octets 1666 for padding or NUL character termination. The syntax and 1667 semantics of this version string are not specified in this 1668 document, since they may vary across products and/or 1669 operating systems. Posture Collectors MAY list two packages 1670 with the same Package Version Number (and even the same 1671 Package Name and Package Version Number) in a single 1672 Installed Packages attribute. The meaning of doing so is not 1673 defined here. 1675 4.2.8. PA-TNC Error 1677 This PA-TNC Attribute Type contains an error code and 1678 supplemental information regarding an error pertaining to PA- 1679 TNC. 1681 All Posture Collectors and Posture Validators that implement any 1682 of the IETF Standard PA Subtypes defined in this specification 1683 MUST support sending and receiving this attribute type, at least 1684 for those PA subtypes. 1686 For this attribute type, the PA-TNC Attribute Vendor ID field 1687 MUST be set to zero (0) and the PA-TNC Attribute Type field MUST 1688 be set to 8. The value in the PA-TNC Attribute Length field 1689 will vary, depending on the length of the Error Information 1690 field. However, the value in the PA-TNC Attribute Length field 1691 MUST be at least 20 because this is the length of the fixed size 1692 fields in the PA-TNC Attribute Header and the fixed size fields 1693 in this attribute type. 1695 A PA-TNC error code SHOULD be sent with the same PA Message 1696 Vendor ID and PA Subtype used by the PA-TNC message that caused 1697 the error so that the error code is sent to the party who sent 1698 the offending PA-TNC message. Other measures (such as setting 1699 PB-TNC's EXCL flag and Posture Collector Identifier or Posture 1700 Validator Identifier fields) SHOULD also be taken to attempt to 1701 ensure that only the party who sent the offending message 1702 receives the error. 1704 When a PA-TNC error code is received, the recipient MUST NOT 1705 respond with a PA-TNC error code because this could result in an 1706 infinite loop of errors. Instead, the recipient MAY log the 1707 error, modify its behavior to attempt to avoid the error 1708 (attempting to avoid loops or long strings of errors), ignore 1709 the error, terminate the assessment, or take other action as 1710 appropriate (as long as it is consistent with the requirements 1711 of this specification). 1713 Posture Validators MUST NOT include this attribute type in an 1714 Attribute Request attribute. It does not make sense for a 1715 Posture Validator to request that a Posture Collector send a PA- 1716 TNC Error attribute. 1718 The following diagram illustrates the format and contents of the 1719 Attribute Value field for this attribute type. The text after 1720 this diagram describes the fields shown here. 1722 1 2 3 1723 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 1724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1725 | Reserved | PA-TNC Error Code Vendor ID | 1726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1727 | PA-TNC Error Code | 1728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1729 | Error Information (Variable Length) | 1730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1732 Reserved 1734 This field is reserved for future use. This field MUST be 1735 set to 0 on transmission and ignored upon reception. 1737 PA-TNC Error Code Vendor ID 1739 This field contains the SMI Private Enterprise Number for the 1740 organization that defined the PA-TNC Error Code that is being 1741 used in the attribute. For IETF Standard PA-TNC Error Code 1742 values this field MUST be set to zero (0). 1744 PA-TNC Error Code 1746 This field contains the PA-TNC Error Code being reported in 1747 this attribute. Note that a particular PA-TNC Error Code 1748 value will have completely different meanings depending on 1749 the PA-TNC Error Code Vendor ID. Each PA-TNC Error Code 1750 Vendor ID defines a different space of PA-TNC Error Code 1751 values. Posture Collectors and Posture Validators MUST NOT 1752 require support for particular vendor-specific PA-TNC Error 1753 Codes and MUST interoperate with other parties despite any 1754 differences in the set of vendor-specific PA-TNC Error Codes 1755 supported (although they MAY permit administrators to 1756 configure them to require support for specific PA-TNC error 1757 codes). 1759 When the PA-TNC Error Code Vendor ID is set to zero (0), the 1760 PA-TNC Error Code is an IETF Standard PA-TNC Error Code. IANA 1761 maintains a registry of PA-TNC Error Codes. Entries in this 1762 registry are added by Expert Review with Specification 1763 Required, following the guidelines in section 7. 1765 The following table lists the IETF Standard PA-TNC Error 1766 Codes defined in this specification: 1768 Value Description 1769 ----- ----------- 1770 0 Reserved 1771 1 Invalid Parameter 1772 2 Version Not Supported 1773 3 Attribute Type Not Supported 1775 The next few subsections of this document provide detailed 1776 definitions of these error codes. 1778 Error Information 1780 This field provides additional context for the error. The 1781 contents of this field vary based on the PA-TNC Error Code 1782 Vendor ID and PA-TNC Error Code. Therefore, whenever a PA-TNC 1783 Error Code is defined, the format of this field for that 1784 error code must also be defined. The definitions of IETF 1785 Standard PA-TNC Error Codes on the next few pages provide 1786 good examples of such definitions. 1788 The length of this field can be determined by the recipient 1789 using the PA-TNC Attribute Length field by subtracting the 1790 length of the fixed-length fields in the PA-TNC Attribute 1791 Header and the fixed-length fields in this attribute. 1793 4.2.8.1. Invalid Parameter Error Code 1795 The Invalid Parameter error code is an IETF Standard PA-TNC 1796 Error Code (value 1) that indicates that the sender of this 1797 error code has detected an invalid value in a PA-TNC message 1798 sent by the recipient of this error code in the current 1799 assessment. 1801 For this error code, the Error Information field contains the 1802 first 8 octets of the PA-TNC message that contained the invalid 1803 parameter and an offset indicating the position within that 1804 message of the invalid parameter. 1806 The following diagram illustrates the format and contents of the 1807 Error Information field for this error code. The text after 1808 this diagram describes the fields shown here. 1810 1 2 3 1811 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 1812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1813 | Version | Reserved | 1814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1815 | Message Identifier | 1816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1817 | Offset | 1818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1820 Version 1822 This field MUST contain an exact copy of the Version field in 1823 the PA-TNC Message Header of the PA-TNC message that caused 1824 this error. 1826 Reserved 1828 This field MUST contain an exact copy of the Reserved field 1829 in the PA-TNC Message Header of the PA-TNC message that 1830 caused this error. 1832 Message Identifier 1834 This field MUST contain an exact copy of the Message 1835 Identifier field in the PA-TNC Message Header of the PA-TNC 1836 message that caused this error. 1838 Offset 1840 This field MUST contain an octet offset from the start of the 1841 PA-TNC Message Header of the PA-TNC message that caused this 1842 error to the start of the value that caused this error. For 1843 instance, if the first PA-TNC attribute in the message had an 1844 invalid PA-TNC Attribute Length (e.g. 0), this value would be 1845 16. 1847 4.2.8.2. Version Not Supported Error Code 1849 The Version Not Supported error code is an IETF Standard PA-TNC 1850 Error Code (value 2) that indicates that the sender of this 1851 error code does not support the PA-TNC version number included 1852 in the PA-TNC Message Header of a PA-TNC message sent by the 1853 recipient of this error code in the current assessment. 1855 For this error code, the Error Information field contains the 1856 first 8 octets of the PA-TNC message that contained the 1857 unsupported version as well as Max Version and Min Version 1858 fields that indicate which PA-TNC version numbers are supported 1859 by the sender of the error code. 1861 The sender MUST support all PA-TNC versions between the Min 1862 Version and the Max Version, inclusive (i.e. including the Min 1863 Version and the Max Version). When possible, recipients of this 1864 error code SHOULD send future messages to the Posture Collector 1865 or Posture Validator that originated this error message with a 1866 PA-TNC version number within the stated range. 1868 Any party that is sending the Version Not Supported error code 1869 MUST include that error code as the only PA-TNC attribute in a 1870 PA-TNC message with version number 1. All parties that send PA- 1871 TNC messages MUST be able to properly process a message that 1872 meets this description, even if they cannot process any other 1873 aspect of PA-TNC version 1. This ensures that a PA-TNC version 1874 exchange can proceed properly, no matter what versions of PA-TNC 1875 the parties implement. 1877 The following diagram illustrates the format and contents of the 1878 Error Information field for this error code. The text after 1879 this diagram describes the fields shown here. 1881 1 2 3 1882 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 1883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1884 | Version | Copy of Reserved | 1885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1886 | Message Identifier | 1887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1888 | Max Version | Min Version | Reserved | 1889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1891 Version 1893 This field MUST contain an exact copy of the Version field in 1894 the PA-TNC Message Header of the PA-TNC message that caused 1895 this error. 1897 Copy of Reserved 1899 This field MUST contain an exact copy of the Reserved field 1900 in the PA-TNC Message Header of the PA-TNC message that 1901 caused this error. 1903 Message Identifier 1905 This field MUST contain an exact copy of the Message 1906 Identifier field in the PA-TNC Message Header of the PA-TNC 1907 message that caused this error. 1909 Max Version 1911 This field MUST contain the maximum PA-TNC version supported 1912 by the sender of this error code. 1914 Min Version 1916 This field MUST contain the minimum PA-TNC version supported 1917 by the sender of this error code. 1919 Reserved 1921 Reserved for future use. This field MUST be set to 0 on 1922 transmission and ignored upon reception. 1924 4.2.8.3. Attribute Type Not Supported Error Code 1926 The Attribute Type Not Supported error code is an IETF Standard 1927 PA-TNC Error Code (value 3) that indicates that the sender of 1928 this error code does not support the PA-TNC Attribute Type 1929 included in the Error Information field. This PA-TNC Attribute 1930 Type was included in a PA-TNC message sent by the recipient of 1931 this error code in the current assessment. 1933 For this error code, the Error Information field contains the 1934 first 8 octets of the PA-TNC message that contained the 1935 unsupported attribute type as well as a copy of the attribute 1936 type that caused the problem. 1938 The following diagram illustrates the format and contents of the 1939 Error Information field for this error code. The text after 1940 this diagram describes the fields shown here. 1942 1 2 3 1943 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 1944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1945 | Version | Reserved | 1946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1947 | Message Identifier | 1948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1949 | Flags | PA-TNC Attribute Vendor ID | 1950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1951 | PA-TNC Attribute Type | 1952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1954 Version 1956 This field MUST contain an exact copy of the Version field in 1957 the PA-TNC Message Header of the PA-TNC message that caused 1958 this error. 1960 Copy of Reserved 1962 This field MUST contain an exact copy of the Reserved field 1963 in the PA-TNC Message Header of the PA-TNC message that 1964 caused this error. 1966 Message Identifier 1968 This field MUST contain an exact copy of the Message 1969 Identifier field in the PA-TNC Message Header of the PA-TNC 1970 message that caused this error. 1972 Flags 1973 This field MUST contain an exact copy of the Flags field in 1974 the PA-TNC Attribute Header of the PA-TNC attribute that 1975 caused this error. 1977 PA-TNC Attribute Vendor ID 1979 This field MUST contain an exact copy of the PA-TNC Attribute 1980 Vendor ID field in the PA-TNC Attribute Header of the PA-TNC 1981 attribute that caused this error. 1983 PA-TNC Attribute Type 1985 This field MUST contain an exact copy of the PA-TNC Attribute 1986 Type field in the PA-TNC Attribute Header of the PA-TNC 1987 attribute that caused this error. 1989 4.2.9. Assessment Result 1991 This PA-TNC attribute contains the final assessment result from 1992 a particular Posture Validator. This attribute might be 1993 returned to a Posture Collector for information purposes such 1994 as when an endpoint is compliant. Similarly, the Assessment 1995 Result attribute could be sent to indicate a non-compliant 1996 result where specific actions are needed to bring an endpoint 1997 into compliance with the network's policies. These actions 1998 could be defined in other PA-TNC attributes such as Remediation 1999 Instructions sent to the Posture Collector. 2001 All Posture Collectors that support an IETF standard PA Subtype 2002 defined in this specification SHOULD support receiving and 2003 processing the Assessment Result attribute. All Posture 2004 Validators that implement an IETF standard PA Subtype defined 2005 in this specification SHOULD support sending the Assessment 2006 Result attribute. 2008 For this attribute type, the PA-TNC Attribute Vendor ID field 2009 MUST be set to zero (0) and the PA-TNC Attribute Type field 2010 MUST be set to 9. 2012 The following diagram illustrates the format and contents of 2013 the Attribute Value field for this attribute type. The text 2014 after this diagram describes the fields shown here. 2016 1 2 3 2017 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 2018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2019 | Assessment Result | 2020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2022 Assessment Result 2024 This 32-bit field MUST contain one of the following values 2026 Value Description 2027 ----- ----------- 2028 0 Posture Validator assessed the endpoint component to 2029 be compliant with policy 2031 1 Posture Validator assessed the endpoint component to 2032 be non-compliant with policy but the difference from 2033 compliant was minor. 2035 2 Posture Validator assessed the endpoint component to 2036 be non-compliant with policy and the assessed 2037 difference was very significant. 2039 3 Posture Validator was unable to determine policy 2040 compliance of an endpoint component due to an error. 2042 4 Posture Validator was unable to determine whether the 2043 assessed endpoint component was compliant with policy 2044 based on the attributes provided by the Posture 2045 Collector(s) 2047 4.2.10. Remediation Instructions 2049 This PA-TNC attribute sent by the Posture Validator to the 2050 Posture Collector(s) contains remediation instructions for 2051 updating a particular component to make the endpoint compliant 2052 with the assessment policies. A Posture Validator might choose 2053 to send more then one Remediation Instructions attributes in 2054 some circumstances (e.g. both a URI and a human readable 2055 message are necessary) to remediate one or more components. 2056 This attribute supports the inclusion of either an IETF 2057 Standard or vendor specific remediation instruction. 2059 All Posture Collectors that implement an IETF standard PA 2060 Subtype defined in this specification SHOULD support receiving 2061 and processing the Remediation Instructions attribute. All 2062 Posture Validators that implement an IETF standard PA Subtype 2063 defined in this specification SHOULD support sending this 2064 attribute type. Posture Collectors and Posture Validators 2065 supporting other non-IETF standard components MAY support this 2066 attribute. 2068 For this attribute type, the PA-TNC Attribute Vendor ID field 2069 MUST be set to zero (0) and the PA-TNC Attribute Type field 2070 MUST be set to 10. 2072 The following diagram illustrates the format and contents of 2073 the Attribute Value field for this attribute type. The text 2074 after this diagram describes the fields shown here. 2076 1 2 3 2077 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 2078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2079 | Reserved | Remediation Parameters Vendor ID | 2080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2081 | Remediation Parameters Type | 2082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2083 | Remediation Parameters (Variable Length) | 2084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2086 Reserved (8 bits) 2088 The Reserved bits MUST be set to 0 on transmission and 2089 ignored on reception. 2091 Remediation Parameters Vendor ID (24 bits) 2093 The Remediation Parameters Vendor ID field identifies a 2094 vendor by using the SMI Private Enterprise Number (PEN). Any 2095 organization can receive its own unique PEN from IANA, the 2096 Internet Assigned Numbers Authority. The Remediation 2097 Parameters Vendor ID qualifies the Remediation Parameters 2098 Type field so that each vendor has 2^32 separate Remediation 2099 Parameters Types available for its use. Remediation 2100 Parameters Types standardized by the IETF are always used 2101 with the value zero (0) in this field. 2103 Remediation Parameters Type (32 bits) 2105 The Remediation Parameters Type field identifies the 2106 different types of remediation instructions that can be 2107 contained in the Remediation Parameters field. IANA 2108 maintains a registry of PA-TNC Remediation Parameters Types. 2109 Entries in this registry are added by Expert Review with 2110 Specification Required, following the guidelines in section 2111 7. A list of IETF Standard PA-TNC Remediation Parameters 2112 Types defined in this specification appears later in this 2113 section. 2115 New vendor-specific remediation instructions can be created 2116 by adding new Remediation Parameters Types (those used with a 2117 non-zero Remediation Parameters vendor ID) without IETF or 2118 IANA involvement. Posture Collectors and Posture Validators 2119 MUST NOT require support for particular vendor-specific PA- 2120 TNC Remediation Parameters Types and MUST interoperate with 2121 other parties despite any differences in the set of vendor- 2122 specific PA-TNC Remediation Parameters Types supported 2123 (although they MAY permit administrators to configure them to 2124 require support for specific PA-TNC remediation parameter 2125 types). 2127 The following table lists the IETF Standard PA-TNC 2128 Remediation Parameters Type values defined in this 2129 specification: 2131 Value Description 2132 ----- ----------- 2133 0 Reserved 2134 1 Remediation URI 2135 2 Remediation String 2137 The next few subsections of this document provide detailed 2138 definitions of the contents of the Remediation Parameters 2139 field used with each Remediation Parameter Type. 2141 Remediation Parameters (variable length) 2143 The Remediation Parameters field contains the actual 2144 remediation instructions for the Posture Collector. 2146 4.2.10.1. Remediation URI Parameters 2148 The Remediation URI parameters type is an IETF Standard 2149 Remediation Parameters Type (value 1) that indicates that the 2150 sending Posture Validator is providing a URI to instructions on 2151 how to remediate the endpoint. 2153 The following diagram illustrates the format and contents of the 2154 Remediation Parameters field when carrying a Remediation URI 2155 parameter. The text after this diagram describes the fields shown 2156 here. 2158 1 2 3 2159 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 2160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2161 | Remediation URI (Variable Length) | 2162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2164 Remediation URI 2166 The Remediation URI field MUST contain a URI, as described in 2167 RFC 3986 [7]. This URI SHOULD contain instructions to update 2168 a particular component so that it might result in the 2169 component being compliant with the policies in future 2170 assessments. Posture Collectors should validate that the URI 2171 and instructions come from a trustworthy source to avoid 2172 being tricked into performing damaging actions (see security 2173 considerations). 2175 4.2.10.2. Remediation String Parameters Type 2177 The Remediation String parameters is an IETF Standard 2178 Remediation Parameters Type (value 2) that indicates that the 2179 sending Posture Validator is providing a human readable string 2180 containing instructions on how to remediate the endpoint. 2182 The following diagram illustrates the format and contents of the 2183 Remediation Parameters field when the carrying a Remediation String 2184 parameter. The text after this diagram describes the fields shown 2185 here. 2187 1 2 3 2188 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 2189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2190 | Remediation String Length | 2191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2192 | Remediation String (Variable Length) | 2193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2194 | Lang Code Len | Remediation String Lang Code (Variable Len) | 2195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2197 Remediation String Length 2198 The Remediation String Length contains the length of the 2199 Remediation String field in octets. 2201 Remediation String 2203 The Remediation String field MUST contain a UTF-8 encoded 2204 string. This string contains human-readable instructions for 2205 remediation that MAY be displayed to the user by the Posture 2206 Collector. NUL termination MUST NOT be included. If a 2207 Posture Collector receives a Remediation String that does 2208 contain a NUL termination, it SHOULD send an Invalid 2209 Parameter error code. 2211 Lang Code Len (Remediation String Language Code Length) 2213 The Lang Code Len field contains the length of the 2214 Remediation String Language Code field in octets. 2216 Remediation String Lang Code 2218 The Remediation String Lang(uage) Code field contains a US- 2219 ASCII string comprised of a well-formed RFC 4646 [6] language 2220 tag that indicates the language(s) used in the Remediation 2221 String in the Remediation Parameters field. A zero length 2222 string MAY be sent for this field (essentially omitting this 2223 field) to indicate that the language code for the remediation 2224 string is not known. 2226 4.2.11. Forwarding Enabled 2228 This PA-TNC attribute indicates whether the endpoint is 2229 forwarding traffic between interfaces. Endpoints that forward 2230 traffic between networks connected to multiple network 2231 interfaces may be considered non-compliant (and a security 2232 risk) in some enterprise network deployments. For example, an 2233 endpoint with multiple connected network interfaces might allow 2234 traffic from an interface connected to a public network to be 2235 forwarded through another interface carrying a VPN session to a 2236 protected enterprise network. This attribute is currently 2237 envisioned to be specific to reporting posture for the 2238 operating system component, however could be useful for other 2239 future types of components. 2241 Posture Collectors that implement the IETF standard PA Subtype 2242 for Operating System SHOULD support sending the Forwarding 2243 Enabled attribute. Posture Collectors that do not implement 2244 the Operating System PA Subtype defined in this specification 2245 SHOULD NOT send the Forwarding Enabled attribute unless if it 2246 is appropriate to their PA Subtype. Whether a particular 2247 Posture Collector actually sends this attribute type SHOULD 2248 still be governed by local privacy and security policies. 2249 Posture Validators that implement the IETF standard PA Subtype 2250 for Operating System SHOULD support receiving the Forwarding 2251 Enabled attribute type. Posture Validators supporting 2252 components other than Operating System MAY support receiving 2253 this attribute type if it is appropriate to their PA Subtype. 2254 A Posture Validator that does not support receiving this 2255 attribute type SHOULD simply ignore attributes with this type. 2256 Posture Validators MUST NOT send this attribute type. 2258 For this attribute type, the PA-TNC Attribute Vendor ID field 2259 MUST be set to zero (0) and the PA-TNC Attribute Type field 2260 MUST be set to 11. 2262 The following diagram illustrates the format and contents of 2263 the Attribute Value field for this attribute type. The text 2264 after this diagram describes the fields shown here. 2266 1 2 3 2267 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 2268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2269 | Forwarding Enabled | 2270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2272 Forwarding Enabled 2274 This 32-bit field MUST contain one of the following values 2276 Value Description 2277 ----- ----------- 2278 0 Disabled - Endpoint is not forwarding traffic. 2280 1 Enabled - Endpoint is forwarding traffic. 2282 2 Unknown - Unable to determine whether endpoint is 2283 forwarding traffic 2285 4.2.12. Factory Default Password Enabled 2287 This PA-TNC attribute indicates whether the endpoint has a 2288 factory default password enabled for use. Some types of 2289 endpoints include a default static password for used to gain 2290 privileged access to the endpoint. If this password is not 2291 changed or disabled before the endpoint is accessible on the 2292 network, it's often easy to compromise the endpoint. 2294 Posture Collectors that implement the IETF standard PA Subtype 2295 for Operating System SHOULD support sending the Factory Default 2296 Password Enabled attribute. Posture Collectors that implement 2297 other IETF Standard PA Subtypes defined in this specification 2298 SHOULD NOT support sending this attribute type for those PA 2299 subtypes. Other Posture Collectors MAY support sending this 2300 attribute type, if it is appropriate to their PA subtype. 2301 Whether a particular Posture Collector actually sends this 2302 attribute type SHOULD still be governed by local privacy and 2303 security policies. Posture Validators that implement the IETF 2304 standard PA Subtype for Operating System SHOULD support 2305 receiving the Factory Default Password Enabled attribute. Other 2306 Posture Validators MAY support receiving this attribute type. A 2307 Posture Validator that does not support receiving this attribute 2308 type SHOULD simply ignore attributes with this type. Posture 2309 Validators MUST NOT send this attribute type. 2311 For this attribute type, the PA-TNC Attribute Vendor ID field 2312 MUST be set to zero (0) and the PA-TNC Attribute Type field MUST 2313 be set to 12. 2315 The following diagram illustrates the format and contents of the 2316 Attribute Value field for this attribute type. The text after 2317 this diagram describes the fields shown here. 2319 1 2 3 2320 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 2321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2322 | Factory Default Password Enabled | 2323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2325 Factory Default Password Enabled 2327 This 32-bit field MUST contain one of the following values 2329 Value Description 2330 ----- ----------- 2331 0 Endpoint does not have factory default password enabled. 2333 1 Endpoint has a factory default password enabled. 2335 4.3. Vendor-Defined Attributes 2337 This section discusses the use of vendor-defined attributes 2338 within PA-TNC. The PA-TNC protocol was designed to allow for 2339 vendor-defined attributes to be used as a replacement where a 2340 standard attribute could be used. In some cases even the 2341 standard attributes allow for vendor-defined information to be 2342 included. It is envisioned that over time as particular vendor- 2343 defined attributes become popular, an equivalent standard 2344 attribute could be added allowing for broader interoperability. 2346 This specification does not define vendor-defined attributes, 2347 but rather highlights how such attributes can be used with PA- 2348 TNC without the potential for name space collisions or 2349 misinterpretations. In order to avoid collisions, PA-TNC uses 2350 the well-established SMI Private Enterprise Numbers as Vendor 2351 IDs to define separate name spaces for important fields within a 2352 PA-TNC message. For example, to ensure the uniqueness of 2353 attribute types while providing for vendor extensions, vendor- 2354 defined attribute types include the vendor's unique Vendor ID, 2355 to indicate the intended name space for the attribute type, 2356 followed by the attribute type. IETF Standard PA-TNC Attribute 2357 Types use a Vendor ID of zero (0). 2359 SMI Private Enterprise Numbers are used to provide a separate 2360 identifier space for each vendor. The IANA provides a registry 2361 for SMI Private Enterprise Numbers. Any organization (including 2362 non-profit organizations, governmental bodies, etc.) can obtain 2363 one of these numbers at no charge and thousands of organizations 2364 have done so. Within this document, SMI Private Enterprise 2365 Numbers are known as "vendor IDs". 2367 5. Security Considerations 2369 This section discusses the major potential types of security 2370 threats relevant to the PA-TNC message protocol. It is 2371 envisioned that additional attribute types could be defined in 2372 the future to facilitate the exchange of security capabilities, 2373 keys, and security protected attributes if future use cases are 2374 adopted that require such protections. 2376 5.1. Trust Relationships 2378 In order to understand where security countermeasures are 2379 necessary, this section starts with a discussion of where the 2380 TNC architecture envisions some trust relationships between the 2381 processing elements of the PA-TNC protocol. The following sub- 2382 sections discuss the trust properties associated with each 2383 portion of the NEA reference model directly involved with the 2384 processing of the PA-TNC protocol. 2386 5.1.1. Posture Collector 2388 The Posture Collectors are trusted by Posture Validators to: 2390 o Collect valid information about the component type associated 2391 with the Posture Collector 2393 o Report upon collected information consistent with local 2394 security and privacy policies 2396 o Accurately report information associated with the type of 2397 component for the PA-TNC message 2399 o Not act maliciously to the Posture Broker Server and Posture 2400 Validators, including attacks such as Denial Of Service 2402 5.1.2. Posture Validator 2404 The Posture Validators are trusted by Posture Collectors to: 2406 o Only request information necessary to assess the security 2407 state of the endpoint 2409 o Make assessment decisions based on deployer defined policies 2411 o Discard collected information consistent with data retention 2412 and privacy policies 2414 o Not act maliciously to the Posture Broker Server and Posture 2415 Collectors, including attacks such as Denial Of Service 2417 o Not to send malicious remediation instructions that do not 2418 fix or causes damage to the endpoint. 2420 5.1.3. Posture Broker Client, Posture Broker Server 2422 The Posture Broker Client and Posture Broker Server are trusted 2423 by the Posture Collector and Posture Validator to: 2425 o Provide a reliable transport for PA-TNC messages 2426 o Deliver messages for a particular PA Subtype only to those 2427 Posture Collectors and Posture Validators that have 2428 registered for them 2430 o Not disclose any provided attributes to unauthorized parties 2432 o Not act maliciously to drop messages, duplicate messages, or 2433 flood the Posture Collectors and Posture Validators with 2434 unnecessary messages 2436 o Not observe, fabricate, or alter the contents of a PA-TNC 2437 message 2439 o Properly place Posture Collector and Posture Validator 2440 identifiers into the PB-TNC protocol, deliver those 2441 identifiers to Posture Collectors and Posture Validators as 2442 needed, and manage exclusive delivery to a particular Posture 2443 Collector or Posture Validator when requested 2445 o Properly expose authentication information from PT security 2446 so that Posture Collectors and Posture Validators can use the 2447 peer's identity information to safely make policy decisions 2449 5.2. Security Threats 2451 Beyond the trusted relationships assumed in section 5.1 the PA- 2452 TNC protocol faces a number of potential security attacks that 2453 could require security countermeasures. 2455 Generally the PA-TNC protocol relies upon the underlying PT 2456 protocol's security to protect the messages from attack when 2457 traveling over the network. Once the message resides on the 2458 Posture Broker Client or Posture Broker Server, the posture 2459 brokers are trusted to properly and safely deliver the messages 2460 to the appropriate Posture Collectors and Posture Validators. 2462 5.2.1. Attribute Theft 2464 When PA-TNC messages are sent over unprotected network links or 2465 spanning local software stacks that are not trusted, the 2466 contents of the PA-TNC messages may be subject to information 2467 theft by an intermediary party. This theft could result in 2468 information being recorded for future use or analysis by the 2469 adversary. Attributes observed by eavesdroppers could contain 2470 information that exposes potential weaknesses in the security of 2471 the endpoint, or system fingerprinting information easing the 2472 ability of the attacker to employ attacks more likely to be 2473 successful against the endpoint. The eavesdropper might also 2474 learn information about the endpoint or network policies that 2475 either singularly or collectively is considered sensitive 2476 information (e.g. certain endpoints are lacking patches, or 2477 particular sub-networks have more lenient policies). 2479 PA-TNC attributes are not intended to carry privacy-sensitive 2480 information, but should some exist in a message, the adversary 2481 could come into possession of the information which could be 2482 used for other financial gain. Therefore it is important that 2483 PT provide strong confidentiality protection to protect the 2484 message from eavesdroppers when being sent between the Posture 2485 Transport Client and Posture Transport Server. 2487 5.2.2. Message Fabrication 2489 Attackers on the network or present within the NEA system could 2490 introduce fabricated PA-TNC messages intending to trick or 2491 create a denial of service against aspects of an assessment. For 2492 example, an adversary could attempt to send a falsified set of 2493 remediation instructions using the Remediation URI support in 2494 hopes of the Posture Collector automatically following the 2495 instructions. Posture Collectors need to ensure that any 2496 requests to take actions on the endpoint (such as remediation 2497 instructions) received from Posture Validator(s) are authentic 2498 and trustworthy using strong authentication and integrity 2499 protections offered by PT. Posture Collectors should not 2500 blindly follow remediation instructions received from a trusted 2501 NEA Server. At least for patches and other potentially 2502 dangerous actions, Posture Collectors should validate these 2503 actions (e.g. via user confirmation) before proceeding. 2505 Such an attack could occur if an active attacker could launch a 2506 man-in-the-middle (MiTM) attack by proxying the PA-TNC messages 2507 and was able to replace undesired messages with ones easing 2508 future attack upon the endpoint. Consider a scenario where PT 2509 security protection is not used and the Posture Broker Server 2510 proxies all assessment traffic to a remote Posture Broker 2511 Server. The proxy could eavesdrop and replace assessment 2512 results attributes, tricking the endpoint into thinking it has 2513 passed an assessment, when in fact it has not and requires 2514 remediation. Because the Posture Collector has no way to verify 2515 that attributes were actually created by an authentic Posture 2516 Validator, it is unable to detect the falsified attribute or 2517 message. Therefore, it is important that PT provides strong 2518 authentication and integrity protection. 2520 5.2.3. Attribute Modification 2522 This attack could allow an active attacker capable of 2523 intercepting a message to modify a PA-TNC message attribute to a 2524 desired value to ease the compromise of an endpoint. Without 2525 the ability for message recipients to detect whether a received 2526 message contains the same content as what was originally sent, 2527 active attackers can stealthily modify the attribute exchange. 2529 For example, an attacker might wish to change the contents of 2530 the firewall component's version string attribute to disguise 2531 the fact that the firewall is running an old, vulnerable 2532 version. The attacker would change the version string sent by 2533 the firewall Posture Collector to the current version number, so 2534 the Posture Validator's assessment passes while leaving the 2535 endpoint vulnerable to attack. Similarly, an attacker could 2536 achieve widespread denial of service by altering large numbers 2537 of assessments' version string attributes to an old value so 2538 they repeatedly fail assessments even after a successful 2539 remediation. Upon receiving the lower value, the Posture 2540 Validator would continue to believe that the endpoint is running 2541 old, potentially vulnerable versions of the firewall that does 2542 not meet network compliance policy, so therefore the endpoint 2543 would not be allowed to join the network. Use of a PT protocol 2544 providing strong integrity protection and authentication is 2545 essential as countermeasures to these attacks. 2547 5.2.4. Attribute Replay 2549 Another potential attack against an unprotected PA-TNC message 2550 attribute exchange is to exploit the lack of a strong binding 2551 between the attributes sent during an assessment to the specific 2552 endpoint. Without a strong binding of the endpoint to the 2553 posture information, an attacker could record the attributes 2554 sent during an assessment of a compliant endpoint and later 2555 replay those attributes so that a non-compliant endpoint can now 2556 gain access to the network or protected resource. This attack 2557 could be employed by a network MiTM that is able to eavesdrop 2558 and proxy message exchanges, or by using local rogue agents on 2559 the endpoints. Assessments lacking some form of freshness 2560 exchange could be subject to replay of prior assessment data, 2561 even if it no longer reflects the current state of the endpoint. 2562 Use of a PT protocol providing strong integrity protection and 2563 authentication including a freshness exchange is necessary 2564 countermeasure to these attacks. 2566 5.2.5. Attribute Insertion 2568 Similar to the attribute modification attacks, an adversary 2569 wishing to include one or more attributes or PA-TNC messages 2570 inside a valid assessment may be able to insert the attributes 2571 or messages without detection by the recipient. For example, an 2572 attacker could add attributes to the front of a PA-TNC message 2573 to cause an assessment to succeed even for a non-compliant 2574 endpoint, particularly if it knew that the recipient ignored 2575 repeated attributes within a message. Similarly, if a Posture 2576 Collector or Posture Validator always generated an error if it 2577 saw unexpected attributes, the attacker could cause failures and 2578 denial of service by adding attributes or messages to an 2579 exchange. Use of a PT protocol providing strong authentication 2580 and integrity protection could prevent the adversary from 2581 inserting attributes into the assessment. 2583 5.2.6. Denial of Service 2585 A variety of types of denial of service attacks are possible 2586 against the PA-TNC message exchange if left unprotected from 2587 untrusted parties along the communication path between the 2588 Posture Collector and Posture Validator. Normally, the PT 2589 exchange is bi-directionally authenticated which helps to 2590 prevent a MiTM on the network from becoming an active proxy, but 2591 transparent message routing gateways may still exist on the 2592 communication path and can modify the integrity of the message 2593 exchange unless adequate integrity protection is provided. If 2594 the MiTM or other entities on the network can send messages to 2595 the Posture Broker Client or Posture Broker Server that appear 2596 to be part of an assessment, these messages could confuse the 2597 Posture Collector and Posture Validator or cause them to perform 2598 unnecessary work or take incorrect action. Several example 2599 denial of service situations are described in sections 5.2.3 2600 and 5.2.5. Many potential denial of service examples exist, 2601 including flooding messages to Posture Collector or Posture 2602 Validator, sending very large messages containing many 2603 attributes, and repeatedly asking for resource intensive 2604 operations. As described in sections 5.1.1 and 5.1.2. 2606 6. Privacy Considerations 2608 The PA-TNC protocol is designed to allow for controlled 2609 disclosure of security relevant information about an endpoint, 2610 specifically for the purpose of enabling an assessment of the 2611 endpoint's compliance with network policy. The purpose of this 2612 protocol is to provide visibility into the state of the 2613 protective mechanisms on the endpoint, in order for the Posture 2614 Validators and Posture Broker Server to determine whether the 2615 endpoint is up to date and thus has the best chance of being 2616 resilient in the face of malware threats. One risk associated 2617 with providing visibility into the contents of an endpoint is 2618 the increased chance for exposure of privacy sensitive 2619 information without the consent of the user. 2621 While this protocol does provide the Posture Validator the 2622 ability to request specific information about the endpoint, the 2623 protocol is not open ended, bounding the Posture Validator to 2624 only query specific information (attributes) about specific 2625 security features (component types) of the endpoint. Each PA- 2626 TNC message is explicitly about a single component from the list 2627 of components in section 3.5. These components include a list 2628 of security-related aspects of the endpoint that affect the 2629 ability of the endpoint to resist attacks and thus are of 2630 interest during an assessment. Discretionary components used by 2631 the user to create or view content are not on the list, as they 2632 are more likely to have access to privacy sensitive information. 2634 Similarly, PA-TNC messages contain a set of attributes which 2635 describe the particular component. Each attribute contains 2636 generic information (e.g. product information or versions) about 2637 the component, so it is unlikely to include any user specific or 2638 identifying information. This combination of limited set of 2639 security related components with non-user specific attributes 2640 greatly reduces the risk of exposure of privacy sensitive 2641 information. Vendors that choose to define additional component 2642 types and/or attributes within their name space are encouraged 2643 to provide similar constraints. 2645 Even with the bounding of standard attribute information to 2646 specific components, it is possible that individuals might wish 2647 to share less information with different networks they wish to 2648 access. For example, a user may wish to share more information 2649 when connecting or being reassessed by the user's employer 2650 network than what would be made available to the local coffee 2651 shop wireless network. While these situations do not impact the 2652 protocol itself, they do suggest that Posture Collector 2653 implementations should consider supporting a privacy filter 2654 allowing the user and/or system owner to restrict access to 2655 certain attributes based upon the target network. 2657 The underlying PT protocol authenticates the network's Posture 2658 Broker Server at the start of an assessment, so identity can be 2659 made available to the Posture Collector and per-network privacy 2660 filtering is possible. Network owners should make available a 2661 list of the attributes they require to perform an assessment and 2662 any privacy policy they enforce when handling the data. Users 2663 wishing to use a more restricted privacy filter on the endpoint 2664 may risk not being able to pass an assessment and thus not gain 2665 access to the requested network or resource. 2667 7. IANA Considerations 2669 This section defines the contents of three new IANA registries: 2670 PA-TNC Attribute Types, PA-TNC Error Codes and PA-TNC 2671 Remediation Parameters Types. This section explains how these 2672 registries work. Also, this specification defines several new 2673 PA Subtypes for use with PA-TNC. 2675 All of the registries defined in this document support IETF 2676 standard values and vendor-defined values. To explain this 2677 phenomenon, we will use the PA-TNC Attribute Type as an example 2678 but the other three registries work the same way. Whenever a PA- 2679 TNC Attribute Type appears on a network, it is always 2680 accompanied by an SMI Private Enterprise Number (PEN), also 2681 known as a vendor ID. If this vendor ID is zero, the 2682 accompanying PA-TNC Attribute Type is an IETF standard value 2683 listed in the IANA registry for PA-TNC Attribute Types and its 2684 meaning is defined in the specification listed for that PA-TNC 2685 Attribute Type in that registry. If the vendor ID is not zero, 2686 the meaning of the PA-TNC Attribute Type is defined by the 2687 vendor identified by the vendor ID (as listed in the IANA 2688 registry for SMI PENs). The identified vendor is encouraged but 2689 not required to register with IANA some or all of the PA-TNC 2690 Attribute Types used with their vendor ID and publish a 2691 specification for each of these values. 2693 This delegation of namespace is analogous to the technique used 2694 for OIDs. It can result in interoperability problems if vendors 2695 require support for particular vendor-specific values. However, 2696 such behavior is explicitly prohibited by this specification, 2697 which dictates that "Posture Collectors and Posture Validators 2698 MUST NOT require support for particular vendor-specific PA-TNC 2699 Attribute Types and MUST interoperate with other parties despite 2700 any differences in the set of vendor-specific PA-TNC Attribute 2701 Types supported (although they MAY permit administrators to 2702 configure them to require support for specific PA-TNC Attribute 2703 Types)." Similar requirements are included for PA Subtypes, 2704 Remediation Parameters Types, and PA-TNC Error Codes. 2706 7.1. Designated Expert Guidelines 2708 For all of the IANA registries defined by this specification, 2709 new values are added to the registry by Expert Review with 2710 Specification Required, using the Designated Expert process 2711 defined in RFC 5226 [3]. 2713 This section provides guidance to designated experts so that 2714 they may make decisions using a philosophy appropriate for these 2715 registries. 2717 The registries defined in this document have plenty of values. 2718 In most cases, the IETF has approximately 2^32 values available 2719 for it to define and each vendor the same number of values for 2720 its use. Because there are so many values available, designated 2721 experts should not be terribly concerned about exhausting the 2722 set of values. 2724 Instead, designated experts should focus on the following 2725 requirements. All values in these IANA registries MUST be 2726 documented in a specification that is permanently and publicly 2727 available. IETF standard values MUST also be useful, not harmful 2728 to the Internet, and defined in a manner that is clear and 2729 likely to ensure interoperability. 2731 Designated experts should encourage vendors to avoid defining 2732 similar but incompatible values and instead agree on a single 2733 IETF standard value. However, it is beneficial to document 2734 existing practice. 2736 There are several ways to ensure that a specification is 2737 permanently and publicly available. It may be published as an 2738 RFC. Alternatively, it may be published in another manner that 2739 makes it freely available to anyone. However, in this latter 2740 case, the vendor MUST supply a copy to the IANA and authorize 2741 the IANA to archive this copy and make it freely available to 2742 all if at some point the document becomes no longer freely 2743 available to all through other channels. 2745 Section 7.2 defines the new PA Subtypes. The following three 2746 sections provide guidance to the IANA in creating and managing 2747 the new IANA registries defined by this specification. 2749 7.2. PA Subtypes 2751 Section 3.5 of this specification defines several new PA 2752 Subtypes that will be added to the PA Subtypes registry defined 2753 in the PB-TNC specification. Here is a list of these 2754 assignments: 2756 PEN Number Name Defining Specification 2757 --- ------ ---- ---------------------- 2758 0 0 Testing RFC # Assigned to this I-D 2759 0 1 Operating System RFC # Assigned to this I-D 2760 0 2 Anti-Virus RFC # Assigned to this I-D 2761 0 3 Anti-Spyware RFC # Assigned to this I-D 2762 0 4 Anti-Malware RFC # Assigned to this I-D 2763 0 5 Firewall RFC # Assigned to this I-D 2764 0 6 IDPS RFC # Assigned to this I-D 2765 0 7 VPN RFC # Assigned to this I-D 2766 0 8 NEA Client RFC # Assigned to this I-D 2768 Once this document becomes an RFC, these PA Subtypes should be 2769 added to the registry for PA Subtypes defined in the PB-TNC 2770 specification. The RFC number assigned to this document should 2771 be associated with these assignments. 2773 7.3. Registry for PA-TNC Attribute Types 2775 The name for this registry is "PA-TNC Attribute Types". Each 2776 entry in this registry should include a human-readable name, an 2777 SMI Private Enterprise Number, a decimal integer value between 0 2778 and 2^32-1, and a reference to the specification where the 2779 contents of this attribute type are defined. This specification 2780 must define the meaning of this PA-TNC attribute type and the 2781 format and semantics of the PA-TNC Attribute Value field for PA- 2782 TNC attributes that include the designated Private Enterprise 2783 Number in the PA-TNC Attribute Vendor ID field and the 2784 designated numeric value in the PA-TNC Attribute Type field. 2786 The following entries for this registry are defined in this 2787 document. Once this document becomes an RFC, they should become 2788 the initial entries in the registry for PA-TNC Attribute Types. 2789 Additional entries to this registry are added by Expert Review 2790 with Specification Required, following the guidelines in section 2791 7.1. 2793 PEN Value Name Defining Specification 2794 --- ----- ---- ---------------------- 2795 0 0 Testing RFC # Assigned to this I-D 2796 0 1 Attribute Request RFC # Assigned to this I-D 2797 0 2 Product Information RFC # Assigned to this I-D 2798 0 3 Numeric Version RFC # Assigned to this I-D 2799 0 4 String Version RFC # Assigned to this I-D 2800 0 5 Operational Status RFC # Assigned to this I-D 2801 0 6 Port Filter RFC # Assigned to this I-D 2802 0 7 Installed Packages RFC # Assigned to this I-D 2803 0 8 PA-TNC Error RFC # Assigned to this I-D 2804 0 9 Assessment Result RFC # Assigned to this I-D 2805 0 10 Remediation Instructions RFC # Assigned to this I-D 2806 0 11 Forwarding Enabled RFC # Assigned to this I-D 2807 0 12 Factory Default Password RFC # Assigned to this I-D 2808 0 0xffffffff Reserved RFC # Assigned to this I-D 2810 7.4. Registry for PA-TNC Error Codes 2812 The name for this registry is "PA-TNC Error Codes". Each entry 2813 in this registry should include a human-readable name, an SMI 2814 Private Enterprise Number, a decimal integer value between 0 and 2815 2^32-1, and a reference to the specification where this error 2816 code is defined. This specification must define the meaning of 2817 this error code and the format and semantics of the Error 2818 Information field for PA-TNC attributes that have a PA-TNC 2819 Vendor ID of 0, a PA-TNC Attribute Type of PA-TNC Error, the 2820 designated Private Enterprise Number in the PA-TNC Error Code 2821 Vendor ID field, and the designated numeric value in the PA-TNC 2822 Error Code field. 2824 The following entries for this registry are defined in this 2825 document. Once this document becomes an RFC, they should become 2826 the initial entries in the registry for PA-TNC Error Codes. 2827 Additional entries to this registry are added by Expert Review 2828 with Specification Required, following the guidelines in section 2829 7.1. 2831 PEN Value Name Defining Specification 2832 --- ----- ---- ---------------------- 2833 0 0 Reserved RFC # Assigned to this I-D 2834 0 1 Invalid Parameter RFC # Assigned to this I-D 2835 0 2 Version Not Supported RFC # Assigned to this I-D 2836 0 3 Attribute Type Not Supported RFC # Assigned to this I-D 2838 7.5. Registry for PA-TNC Remediation Parameters Types 2840 The name for this registry is "PA-TNC Remediation Parameters 2841 Types". Each entry in this registry should include a human- 2842 readable name, an SMI Private Enterprise Number, a decimal 2843 integer value between 1 and 2^32-1, and a reference to the 2844 specification where the contents of this remediation parameters 2845 type are defined. This specification must define the meaning of 2846 this PA-TNC Remediation Parameters Type and the format and 2847 semantics of the Remediation Parameters field for PA-TNC 2848 attributes that include the designated Private Enterprise Number 2849 in the Remediation Parameters Vendor ID field and the designated 2850 numeric value in the Remediation Parameters Type field. 2852 The following entries for this registry are defined in this 2853 document. Once this document becomes an RFC, they should become 2854 the initial entries in the registry for PA-TNC Remediation 2855 Parameters Types. Additional entries to this registry are added 2856 by Expert Review with Specification Required, following the 2857 guidelines in section 7.1. 2859 PEN Value Name Defining Specification 2860 --- ----- ---- ---------------------- 2861 0 0 Reserved RFC # Assigned to this I-D 2862 0 1 URI RFC # Assigned to this I-D 2863 0 2 Remediation String RFC # Assigned to this I-D 2865 8. Acknowledgments 2867 Thanks to the Trusted Computing Group for contributing the 2868 initial text [8] upon which this document was based. The 2869 authors of this draft would also like to acknowledge the 2870 following people who have contributed to or provided substantial 2871 input on the preparation of this document or predecessors to it: 2872 Stuart Bailey, Roger Chickering, Lauren Giroux, Charles 2873 Goldberg, Steve Hanna, Ryan Hurst, Meenakshi Kaushik, Greg 2874 Kazmierczak, Scott Kelly, PJ Kirner, Houcheng Lee, Lisa 2875 Lorenzin, Mahalingam Mani, Sung Lee, Ravi Sahita, Mauricio 2876 Sanchez, Brad Upson, and Han Yin. 2878 This document was prepared using 2-Word-v2.0.template.dot. 2880 9. References 2882 9.1. Normative References 2884 [1] Bradner, S., "Key words for use in RFCs to Indicate 2885 Requirement Levels", BCP 14, RFC 2119, March 1997. 2887 [2] F. Yergeau, "UTF-8, a transformation format of ISO 10646", 2888 RFC 3629, November 2003. 2890 [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2891 IANA Considerations Section in RFCs", RFC 5226, May 2008. 2893 [4] Klyne, G. and C. Newman, "Date and Time on the Internet: 2894 Timestamps", RFC 3339, July 2002. 2896 [5] Sahita, R., Hanna, S., and R. Hurst, "PB-TNC: A Posture 2897 Broker Protocol (PB) Compatible with TNC", draft-ietf-nea- 2898 pb-tnc-06.txt, Work In Progress, October 2009. 2900 [6] Phillips, A. and Davis, M., "Tags for the Identification 2901 of Languages", RFC 4646, September 2006. 2903 [7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2904 Resource Identifier (URI): Generic Syntax", RFC 3986, 2905 January 2005. 2907 9.2. Informative References 2909 [8] Trusted Computing Group, "IF-M: TLV Binding", February 2910 2008. 2912 [9] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 2913 Tardo, "Network Endpoint Assessment (NEA): Overview and 2914 Requirements", RFC 5209, June 2008. 2916 Appendix A: Use Cases 2918 A.1. Initial Client triggered assessment 2920 This scenario involves the assessment of an endpoint initiated 2921 during network join. The assessment is triggered by the Posture 2922 Broker Client (PBC) and involves collection of patch information 2923 from both Standard Operating System (OS) Posture Collector and 2924 vendor-specific Patch Posture Collector (PC). The assessment by 2925 both the vendor-specific Patch Posture Validator (PV) and 2926 Standard OS Posture Validator result in a compliant assessment 2927 decision which results in a compliant System Assessment Decision 2928 to be returned by the Posture Broker Server (PBS). 2930 +--------+ +-------+ +---------+ +--------+ +-------++--------+ 2931 | Vndr. X| | Std. | | Std. | | Std. | | Std. || Vndr. X| 2932 |Patch PC| | OS PC | | PBC | | PBS | | OS PV ||Patch PV| 2933 +--+-----+ +-+-----+ +---+-----+ +-+------+ +-+------+--+-----+ 2934 | | N/W Join| | | | 2935 | | ----->| | | | 2936 | | Req Post. | | | | 2937 | |<----------| | | | 2938 | | Req Post. | | | | 2939 |<--------------------| | | | 2940 |Vndr X Patch Posture | | | | 2941 |-------------------->| | | | 2942 | |OS Posture | | | | 2943 | |---------->| | | | 2944 | | | Posture | | | 2945 | | | Report | | | 2946 | | |-------->| | | 2947 | | | | Verify | | 2948 | | | | Posture | | 2949 | | | |---------> | 2950 | | | | | Verify | 2951 | | | | | Posture | 2952 | | | |------------------->| 2953 | | | | OS Reslt | | 2954 | | | |<---------| | 2955 | | | | VndrX Patch Result | 2956 | | | Assess |<-------------------| 2957 | | | Result | | 2958 | | |<--------| | | 2959 | | OS Reslt | | | | 2960 | |<----------| | | | 2961 | VndrX Patch Result | | | | 2962 |<--------------------| | | | 2964 A.1.1. Message Contents 2966 This section shows the contents of the key fields in each of the 2967 PA messages exchanged in this use case. When necessary 2968 additional commentary is provided to explain why certain fields 2969 contain the shown values. Note that many of the flows shown are 2970 between components on the same system so no message contents are 2971 shown. 2973 A.1.1.1. N/W Join 2975 This flow represents the event that causes the PBC to decide to 2976 start an assessment of the endpoint in order to gain access to 2977 the network. This is merely an event and does not include a 2978 message being sent. 2980 A.1.1.2. Request Posture (Req Post.) 2982 This flow illustrates an invocation of the OS and patch posture 2983 collectors requesting particular posture attributes to be sent. 2984 Because this use case is triggered locally the contents of this 2985 flow aren't specified by NEA. 2987 A.1.1.3. Vendor X Patch Posture (VndrX Patch Posture) 2989 This flow contains the PA message from the Patch Posture 2990 Collector: 2992 Vendor X Patch Posture PA Message { 2993 Attribute HDR {Message ID} 2994 Attribute 1 { 2995 vendor-id=1 (vendor X) 2996 type=1 (Vendor X namespace attribute) 2997 length 2998 Value = { 2999 VendorXAttribute1=123 3000 } 3001 } 3002 Attribute 2 { 3003 vendor-id=1 (vendor X) 3004 type=2 (Vendor X namespace attribute) 3005 length 3006 Value = { 3007 VendorXAttribute2=456 3008 } 3009 } 3010 } 3012 A.1.1.4. OS Posture 3014 This flow contains the PA message from the OS Posture Collector: 3016 OS Posture PA Message { 3017 Attribute HDR {Message ID} 3018 Attribute 1 { 3019 vendor-id=0 3020 type=2 (product information) 3021 length 3022 Value = { 3023 Product-vendor-id=311 -- Microsoft's PEN 3024 Product-name="Windows Vista" 3025 } 3026 } 3027 Attribute 2 { 3028 vendor-id=0 3029 type=3 (numeric version) 3030 length 3031 Value = { 3032 major-version=6 -- Vista is version 6.0 3033 minor-version=0 3034 build-number=456789 3035 service-pack-major=0 -- No service packs 3036 service-pack-minor=0 3037 } 3038 } 3039 } 3041 A.1.1.5. Posture Report 3043 This flow contains the PB message containing the PA messages 3044 from the Patch and OS Posture Collectors; the message content is 3045 described in the PB-TNC specification. 3047 A.1.1.6. Verify Posture 3049 This flow illustrates an invocation of the OS and patch Posture 3050 Validators requesting verification of the posture attributes 3051 received. Because this flow happens locally within the NEA 3052 server, NEA does not specify the message contents. 3054 A.1.1.7. OS Posture Result (OS Reslt) 3056 This flow contains the PA message (Posture Assessment Result) 3057 from the OS Posture Validator 3059 OS Posture Result PA Message { 3060 Attribute HDR {Message ID} 3061 Attribute 1 { 3062 vendor-id=0 3063 type=9 (assessment-result) 3064 length 3065 Value = { 3066 assessment-result=0 (compliant) 3067 } 3068 } 3069 } 3071 A.1.1.8. Vendor X Patch Result (VndrX Patch Result) 3073 This flow contains the PA message (Posture Assessment Result) 3074 from the Vendor X Patch Posture Validator 3076 Patch Vendor X Posture Result PA Message { 3077 Attribute HDR {Message ID} 3078 Attribute 1 { 3079 vendor-id=0 3080 type=9 (assessment-result) 3081 length 3082 Value = { 3083 assessment-result=0 (compliant) 3084 } 3085 } 3086 } 3088 A.1.1.9. Assessment Result (Assess Result) 3090 This flow contains the PB message containing the system 3091 assessment result computed by the Posture Broker Server and the 3092 PA messages from the Patch and OS Posture Validators; the 3093 message content is described in the PB-TNC specification. 3095 A.1.1.10. Posture Result (OS PRslt & Vndr X Post PResult) 3097 These flows illustrate an invocation of the OS and Vendor X 3098 Patch Posture Collectors to receive the posture assessment 3099 results. Because this flow is triggered locally, NEA does not 3100 specify the contents of this flow. 3102 A.2. Server initiated Assessment with Remediation 3104 This scenario involves the assessment of an endpoint initiated 3105 by the NEA Server. The assessment is triggered by the Posture 3106 Broker Server and involves collection of Anti-Virus attributes 3107 for two Anti-Virus components running on the endpoint. The 3108 endpoint is assessed to be compliant by one of the vendor 3109 (Vendor X) anti-virus Posture Validators and non-complaint by 3110 the other vendor (Vendor Y) anti-virus Posture Validator. Based 3111 upon the Posture Broker Server's policy, this results in a non- 3112 compliant system assessment decision to be returned by the 3113 Posture Broker Server. The Posture Broker Server also returns 3114 remediation instructions for the endpoint as part of the 3115 response. 3117 +--------+ +-------+ +---------+ +--------+ +-------+ +--------+ 3118 | Vndr Y | | Vndr X| | Std. | | Std. | | Vndr X| | Vndr Y | 3119 | AV PC | | AV PC | | PBC | | PBS | | AV PV | | AV PV | 3120 +----+---+ +---+---+ +-----+---+ +---+----+ +---+---+ +----+---+ 3121 | | | N/W Join| | | 3122 | | | ------->| | | 3123 | | | | Create | | 3124 | | | |Post. Req | | 3125 | | | |--------->| | 3126 | | | |Create Posture Req | 3127 | | | |----------+--------->| 3128 | | | | Vndr Y AV Post Req | 3129 | | | |<---------+----------| 3130 | | | |Vndr X AV | | 3131 | | | |Post. Req | | 3132 | | | Posture |<---------| | 3133 | | | Request | | | 3134 | | Vndr X AV |<--------| | | 3135 | | Post. Req | | | | 3136 | |<----------| | | | 3137 | Vndr Y AV | | | | 3138 | Posture Req | | | | 3139 +<---------+-----------| | | | 3140 | Vndr Y AV Posture | | | | 3141 +----------+---------->| | | | 3142 | | Vndr X AV | | | | 3143 | | Posture | | | | 3144 | |---------->| Posture | | | 3145 | | |Response | | | 3146 | | |-------->| | | 3147 | | | | Verify | | 3148 | | | | Posture | | 3149 | | | |--------->| | 3150 | | | | Verify Posture | 3151 | | | |----------+--------->| 3152 | | | |Vndr Y AV Post Result| 3153 | | | |<---------+----------| 3154 | | | |Vndr X AV | | 3155 | | | |Post Reslt| | 3156 | | | Assess |<---------| | 3157 | | | Result | | | 3158 | | Vndr X AV |<--------| | | 3159 | |Post Reslt |<--------| | | 3160 | |<----------| | | | 3161 | Vndr Y AV Post Reslt | | | | 3162 +<---------+-----------| | | | 3164 A.2.1. Message Contents 3166 This section shows the contents of the key fields in each of the 3167 PA messages exchanged in this use case. When necessary 3168 additional commentary is provided to explain why certain fields 3169 contain the shown values. Note that many of the flows shown are 3170 between components on the same system so no message contents are 3171 shown. 3173 A.2.1.1. N/W Join 3175 This flow represents the event that causes the PBS to decide to 3176 start an assessment of the endpoint in order to gain access to 3177 the network. This is merely an event and does not include a 3178 message being sent. 3180 A.2.1.2. Create Posture Request (Create Posture Req.) 3182 This flow illustrates an invocation of the Vendor X and Vendor Y 3183 Anti-Virus Posture Validators enabling posture request 3184 attributes to be created. Because this use case is triggered 3185 locally, NEA does not specify the contents of this flow. 3187 A.2.1.3. Vendor Y AV Posture Request (Vndr Y AV Posture Req) 3189 This flow contains the PA message (Posture Request) from the 3190 Vendor Y Anti-Virus Posture Validator 3192 Vendor Y AV Posture Request PA Message { 3193 Attribute HDR {Message ID} 3194 Attribute 1 { 3195 vendor-id=0 3196 type=1 (Attribute Request) 3197 length 3198 Value = { 3199 Vendor-id=0 (IETF Standard) 3200 Type=2 (Standard attribute, Product-Information) 3201 Vendor-id=1 (Vendor Y) 3202 Type=2 (Vendor Y attribute, Extended-Dat-Version) 3203 } 3205 } 3206 } 3208 A.2.1.4. Vendor X AV Posture Request (Vndr X AV Post. Req) 3210 This flow contains the PA message (Posture Request) from the 3211 Vendor X Anti-Virus Posture Validator 3213 Vendor X AV Posture Request PA Message { 3214 Attribute HDR {Message ID} 3215 Attribute 1 { 3216 vendor-id=0 3217 type=1 (Attribute Request) 3218 length 3219 Value = { 3220 Vendor-id=1 (Vendor X) 3221 Type=1 (Vendor X attribute, Scan-Engine-Version) 3222 Vendor-id=0 (IETF Standard) 3223 Type=5 (Standard, Operational-Status) 3224 } 3225 } 3226 } 3228 A.2.1.5. Posture Request 3230 This flow contains the PB message containing the PA messages 3231 from the Vendor X and Vendor Y Anti-Virus Posture Validators; 3232 the message content is described in the PB-TNC specification. 3234 A.2.1.6. Posture Request (Vndr X AV Post Req & Vndr Y AV Post Req) 3236 These flows illustrate an invocation of the Vendor X and Vendor 3237 Y Anti-Virus Posture Collectors to process the Posture Request 3238 and return the particular posture attributes requested. Because 3239 this flow is triggered locally, NEA does not specify the 3240 contents of this flow. 3242 A.2.1.7. Vendor Y AV Posture (Vndr Y AV Posture) 3244 This flow contains the PA message (response to the Posture 3245 Request) from the Vendor Y Anti-Virus Posture Collector. 3247 Vendor Y AV Posture PA Message { 3248 Attribute HDR {Message ID} 3249 Attribute 1 { 3250 vendor-id=0 (IETF Standard) 3251 Type=2 (Standard attribute, Product-Information) 3252 length 3253 Value = { 3254 product-vendor-id=12345 (vendor Y) 3255 product-id=987 (AV product id from vendor Y) 3256 product-name="Vendor Y Anti-Virus" 3257 } 3258 } 3259 Attribute 2 { 3260 vendor-id=2 (vendor Y) 3261 type=2 (vendor Y attribute, DAT-Version) 3262 length 3263 Value = { 3264 DAT-version=5678 3265 } 3266 } 3267 } 3269 A.2.1.8. Vendor X AV Posture (Vndr X AV Posture) 3271 This flow contains the PA message (response to the Posture 3272 Request) from the Vendor X Anti-Virus Posture Collector. 3274 Vendor X AV Posture PA Message { 3275 Attribute HDR {Message ID} 3276 Attribute 1 { 3277 vendor-id=1 3278 type=1 (vendor X attribute, Scan-Engine-Version) 3279 length 3280 Value = { 3281 scan-engine-version=1234 3282 } 3283 } 3284 Attribute 2 { 3285 vendor-id=0 (IETF Standard) 3286 type=5 (Standard, Operational-Status) 3287 length 3288 Value = { 3289 status=2 (installed but non-operational) 3290 result=0 (unknown) 3291 last use="" (never used) 3292 } 3293 } 3294 } 3296 A.2.1.9. Posture Response 3298 This flow contains the PB message containing the PA messages 3299 from the Vendor X and Vendor Y Anti-Virus Posture Collectors; 3300 the message content is described in the PB-TNC specification. 3302 A.2.1.10. Verify Posture 3304 This flow illustrates an invocation of the Vendor X and Vendor Y 3305 Anti-Virus Posture Validators requesting verification of the 3306 posture attributes received. Because this flow happens locally 3307 within the NEA server, NEA does not specify the message 3308 contents. 3310 A.2.1.11. Vendor Y AV Posture Result (Vndr Y AV Post Result) 3312 This flow contains the PA message (Posture Assessment Result) 3313 from the Vendor Y Anti-Virus Posture Validator 3315 Vendor Y AV Posture Result PA Message { 3316 Attribute HDR {Message ID} 3317 Attribute 1 { 3318 vendor-id=0 3319 type=9 (assessment-result) 3320 length 3321 Value = { 3322 assessment-result=0 (compliant) 3323 } 3324 } 3325 } 3327 A.2.1.12. Vendor X AV Posture Result (Vndr X AV Post Reslt) 3329 This flow contains the PA message (Posture Assessment Result) 3330 from the Vendor X Anti-Virus Posture Validator 3332 Vendor X AV Posture Result PA Message { 3333 Attribute HDR {Message ID} 3334 Attribute 1 { 3335 vendor-id=0 3336 type=9 (assessment-result) 3337 length 3338 Value = { 3339 assessment-result=1 (non-compliant) 3340 } 3341 } 3342 } 3344 A.2.1.13. Assessment Result (Assess Result) 3346 This flow contains the PB message containing the system 3347 assessment result computed by the Posture Broker Server and the 3348 PA messages from the Vendor X and Vendor Y Anti-Virus Posture 3349 Validators; the message content is described in the PB-TNC 3350 specification. 3352 A.2.1.14. Posture Result (Vndr X AV Post Reslt & Vndr Y AV Post 3353 Reslt) 3355 These flows illustrate an invocation of the Vendor X and Vendor 3356 Y Anti-Virus Posture Collectors to receive the posture 3357 assessment results. Because this flow is triggered locally, NEA 3358 does not specify the contents of this flow. 3360 A.3. Client triggered re-assessment 3362 This scenario involves the re-assessment of an endpoint as a 3363 result of enabling a software component on the endpoint. The 3364 endpoint has two VPN client software components, one from vendor 3365 X for the user's home network and other from vendor Y for the 3366 network that the endpoint is currently accessing. The 3367 assessment is triggered when the user tries to use the Vendor X 3368 VPN client; this is a violation of the assessment policy. The 3369 Posture Broker Client triggers the posture assessment when it 3370 receives a notification from the VPN Posture Collector about the 3371 change to the operational state of the VPN component on the 3372 endpoint. Note that the VPN Posture Collector may support 3373 standard attributes and some vendor defined attributes from 3374 vendor X and vendor Y's namespaces. This use case does not 3375 leverage vendor defined attributes. The assessment involves 3376 verification of the standard VPN posture attributes by the 3377 standard VPN Posture Validator that results in a non-compliant 3378 assessment result. 3380 This use case relies on the use of multiple Posture Collector 3381 IDs for a single Posture Collector as described in section 3.3 3382 of the PA-TNC specification. In this example, the Posture 3383 Collector will obtain two Posture Collector IDs to a single 3384 Posture Collector (Standard VPN PC) and the Posture Collector 3385 will generate two separate PA messages each using a different ID 3386 to report the posture for Vendor X and Vendor Y VPN Clients. 3387 The Posture Broker Client will associate the assigned IDs in the 3388 PB message sent to the NEA Server. This entire behavior will be 3389 completely opaque to the NEA Server, which will handle the PB 3390 message as if there were two VPN Posture Collectors on the NEA 3391 Client. 3393 +--------+ +-------+ +---------+ +--------+ +-------+ +--------+ 3394 |Vndr X | |Vndr Y | |Standard | |Standard| |Standrd| |Standard| 3395 |VPNClnt | |VPNClnt| | VPN PC | | PBC | | PBS | | VPN PV | 3396 +----+---+ +---+---+ +-----+---+ +---+----+ +---+---+ +----+---+ 3397 Enble| | | | | | 3398 ---->| | | | | | 3399 | VPN Status Change | | | | 3400 |--------------------->| Posture | | | 3401 | | | Change | | | 3402 | | |-------->| | | 3403 | | |Req. Post| | | 3404 | | |<--------| | | 3405 | |Ins/Rq Info| | | | 3406 | |<----------| | | | 3407 | Inspect/Request Info | | | | 3408 |<---------+-----------|VPNX Post| | | 3409 | | |-------->| | | 3410 | | |VPNY Post| | | 3411 | | |-------->| | | 3412 | | | | Posture | | 3413 | | | | Report | | 3414 | | | |--------->| | 3415 | | | | |Vrfy Post.| 3416 | | | | |--------->| 3417 | | | | |VPN PRslt | 3418 | | | | Assess |<---------| 3419 | | | | Result | | 3420 | | | |<---------| | 3421 | | |VPN PRslt| | | 3422 | | |<--------| | | 3424 A.3.1. Message Contents 3426 This section shows the contents of the key fields in each of the 3427 PA messages exchanged in this use case. When necessary 3428 additional commentary is provided to explain why certain fields 3429 contain the shown values. Note that many of the flows shown are 3430 between components on the same system so no message contents are 3431 shown. 3433 A.3.1.1. Enable VPN Client (Enble) 3435 This flow represents the end user triggered event of starting 3436 the VPN Client software from Vendor X. This is merely an event 3437 and does not include a message being sent. 3439 A.3.1.2. Notify Status Change (VPN Status Change) 3441 This flow represents the detection of the active state of the 3442 Vendor X VPN Client software by the VPN Posture Collector. This 3443 is merely an event and does not include a message being sent. 3445 A.3.1.3. Notify Posture Change (Posture Change) 3447 This flow represents the notification of the VPN posture change 3448 sent from the VPN Posture Collector to the Standard Posture 3449 Broker Client. This is merely an event and does not include a 3450 message being sent. 3452 A.3.1.4. Request Posture (Req. Post) 3454 This flow illustrates an invocation of the VPN Posture Collector 3455 requesting particular posture attributes to be sent. Because 3456 this use case is triggered locally, NEA does not specify the 3457 contents of this flow. 3459 A.3.1.5. Inspect/Request Info (Ins/Rq Info) 3461 This flow illustrates the acquisition of the posture information 3462 by the VPN Posture Collector from the Vendor X and Vendor Y VPN 3463 Client components. Because this flow is triggered locally, NEA 3464 does not specify the message contents. 3466 A.3.1.6. Vendor X VPN Posture (VPNX Post) 3468 This flow contains the PA message from the VPN Posture Collector 3469 describing the Vendor X VPN Client's posture: 3471 Vendor X VPN Posture PA Message{ 3472 Attribute HDR {Message ID} 3473 Attribute 1 { 3474 vendor-id=0 3475 type=2 (product information) 3476 length 3477 Value = { 3478 product-vendor-id=9876 (vendor X) 3479 product-id=567 (VPN client identifier for Vndr X) 3480 product-name="Vendor X VPN Client" 3481 } 3482 } 3483 Attribute 2 { 3484 vendor-id=0 3485 type=5 (operational status) 3486 length 3487 Value = { 3488 Status=3 (Operational) 3489 Result=1 (Successful use with no errors detected) 3490 last Use="2008-07-07T12:00:00Z" 3491 } 3492 } 3494 A.3.1.7. Vendor Y VPN Posture (VPNY Post) 3496 This flow contains the PA message from the VPN Posture Collector 3497 including the Vendor Y VPN Client's posture: 3499 Vendor Y VPN Posture PA Message{ 3500 Attribute HDR {Message ID} 3501 Attribute 1 { 3502 vendor-id=0 3503 type=2 (product information) 3504 length 3505 Value = { 3506 product-vendor-id=Vendor Y 3507 product-id=234 (VPN client identifier for Vndr Y) 3508 product-name="Vendor Y VPN Client" 3509 } 3510 } 3511 Attribute 2 { 3512 vendor-id=0 3513 type=5 (operational status) 3514 length 3515 Value = { 3516 Status=3 (Operational) 3517 Result=1 (Successful use with no errors detected) 3518 last Use="2008-07-07T14:05:00Z" 3519 } 3520 } 3521 } 3523 A.3.1.8. Posture Report 3525 This flow contains the PB message containing the PA message from 3526 the VPN Posture Collector; the message content is described in 3527 the PB-TNC specification. 3529 A.3.1.9. Verify Posture (Vrfy Post.) 3531 This flow illustrates an invocation of the VPN Posture Validator 3532 requesting verification of the posture attributes received. 3533 Because this flow happens locally within the NEA server, NEA 3534 does not specify the message contents. 3536 A.3.1.10. VPN Posture Result (VPN PRslt) 3538 This flow contains the PA message (Posture Assessment Result) 3539 from the VPN Posture Validator 3541 VPN Posture Result PA Message { 3542 Attribute HDR {Message ID} 3543 Attribute 1 { 3544 vendor-id=0 3545 type=9 (assessment-result) 3546 length 3547 Value = { 3548 assessment-result=1 (non-compliant) 3549 } 3550 } 3551 } 3553 A.3.1.11. Assessment Result (Assess Result) 3555 This flow contains the PB message containing the system 3556 assessment result computed by the Posture Broker Server and the 3557 PA messages from the VPN Posture Validator; the message content 3558 is described in the PB-TNC specification. 3560 A.3.1.12. Posture Result (VPN PRslt) 3562 This flow illustrates an invocation of the VPN Posture Collector 3563 to receive the posture assessment result. Because this flow is 3564 triggered locally, NEA does not specify the contents of this 3565 flow. 3567 Appendix B: Evaluation Against NEA Requirements 3568 This section evaluates the PA-TNC protocol against the 3569 requirements defined in the NEA Requirements document. Each 3570 subsection considers a separate requirement from the NEA 3571 Requirements document. Only common requirements (C-1 through C- 3572 10) and PA requirements (PA-1 through PA-6) are considered, 3573 since these are the only ones that apply to PA. 3575 B.1. Evaluation Against Requirements C-1 3577 Requirement C-1 says: 3579 C-1 NEA protocols MUST support multiple round trips between 3580 the NEA Client and NEA Server in a single assessment. 3582 PA-TNC meets this requirement. It allows an unlimited number of 3583 round trips between the NEA Client and NEA Server. 3585 B.2. Evaluation Against Requirements C-2 3587 Requirement C-2 says: 3589 C-2 NEA protocols SHOULD provide a way for both the NEA Client 3590 and the NEA Server to initiate a posture assessment or 3591 reassessment as needed. 3593 PA-TNC meets this requirement. PA-TNC is designed to work 3594 whether the NEA Client or the NEA Server initiates a posture 3595 assessment or reassessment. 3597 B.3. Evaluation Against Requirements C-3 3599 Requirement C-3 says: 3601 C-3 NEA protocols including security capabilities MUST be 3602 capable of protecting against active and passive attacks by 3603 intermediaries and endpoints including prevention from replay 3604 based attacks. 3606 Security for PA-TNC messages being sent over the network is 3607 provided through PT protocol security. Therefore, PA-TNC 3608 does not include any security capabilities. Since this 3609 requirement only applies to NEA protocols "including security 3610 capabilities", this specification is not subject to this 3611 requirement (see section 5.2). 3613 B.4. Evaluation Against Requirements C-4 3615 Requirement C-4 says: 3617 C-4 The PA and PB protocols MUST be capable of operating over 3618 any PT protocol. For example, the PB protocol must provide a 3619 transport independent interface allowing the PA protocol to 3620 operate without change across a variety of network protocol 3621 environments (e.g. EAP/802.1X, PANA, TLS and IKE/IPsec). 3623 PA-TNC meets this requirement. PA-TNC can operate over any PT 3624 protocol that meets the requirements for PT stated in the NEA 3625 Requirements document. PA-TNC does not have any dependencies on 3626 specific details of the underlying PT protocol. 3628 B.5. Evaluation Against Requirements C-5 3630 Requirement C-5 says: 3632 C-5 The selection process for NEA protocols MUST evaluate and 3633 prefer the reuse of existing open standards that meet the 3634 requirements before defining new ones. The goal of NEA is not 3635 to create additional alternative protocols where acceptable 3636 solutions already exist. 3638 Based on this requirement, PA-TNC should receive a strong 3639 preference. PA-TNC is equivalent with IF-M 1.0, an open TCG 3640 specification. Other specifications from TCG and other groups 3641 are also under development based on the IF-M 1.0 specification. 3642 Selecting PA-TNC as the basis for the PA protocol will ensure 3643 compatibility with IF-M 1.0, with these other specifications, 3644 and with their implementations. 3646 B.6. Evaluation Against Requirements C-6 3648 Requirement C-6 says: 3650 C-6 NEA protocols MUST be highly scalable; the protocols MUST 3651 support many Posture Collectors on a large number of NEA Clients 3652 to be assessed by numerous Posture Validators residing on 3653 multiple NEA Servers. 3655 PA-TNC meets this requirement. PA-TNC supports an unlimited 3656 number of Posture Collectors, Posture Validators, NEA Clients, 3657 and NEA Servers. It also is quite scalable in many other 3658 aspects as well. A PA-TNC message can contain up to 2^32-1 3659 octets and about 2^28 PA-TNC attributes. Each organization with 3660 an SMI Private Enterprise Number is entitled to define up to 3661 2^32 vendor-specific PA-TNC Attribute Types, 2^16 vendor- 3662 specific PA-TNC Product IDs, and 2^32 vendor-specific PA-TNC 3663 Error Codes. Each attribute can contain almost 2^32 octets. It 3664 is generally not advisable or necessary to send this much data 3665 in a NEA assessment, but still PA-TNC is highly scalable and 3666 meets requirement C-6 easily. 3668 B.7. Evaluation Against Requirements C-7 3670 Requirement C-7 says: 3672 C-7 The protocols MUST support efficient transport of a large 3673 number of attribute messages between the NEA Client and the NEA 3674 Server. 3676 PA-TNC meets this requirement. Each PA-TNC message can contain 3677 about 2^28 PA-TNC attributes. PA-TNC supports up to 2^32 round 3678 trips in a session so the maximum number of attribute messages 3679 that can be sent in a single session is actually about 2^50. 3680 However, it is generally inadvisable and unnecessary to send a 3681 large number of messages in a NEA assessment. As for 3682 efficiency, PA-TNC adds only 12 octets of overhead per attribute 3683 and 8 octets per message (which is negligible on a per-attribute 3684 basis). 3686 B.8. Evaluation Against Requirements C-8 3688 Requirement C-8 says: 3690 C-8 NEA protocols MUST operate efficiently over low bandwidth 3691 or high latency links. 3693 PA-TNC meets this requirement. A PA-TNC exchange is envisioned 3694 (based on current deployment experience) to involve one or two 3695 round trips with less than 500 octets of PA-TNC messages. Of 3696 course, use of vendor-specific PA-TNC attribute types could 3697 expand the assessment. However, PA-TNC itself imposes an 3698 overhead of only 8 octets per PA-TNC message and 12 octets per 3699 attribute. 3701 B.9. Evaluation Against Requirements C-9 3703 Requirement C-9 says: 3705 C-9 For any strings intended for display to a user, the 3706 protocols MUST support adapting these strings to the user's 3707 language preferences. 3709 PA-TNC meets this requirement. The only field included in a PB- 3710 TNC attribute for display to the user includes a language tag 3711 that could be selected based upon the user's PB-TNC negotiated 3712 preferred language for the assessment (see section 4.10 of the 3713 PB-TNC specification). With this exception, all of the strings 3714 in the standard PA-TNC attributes are intended for logging and 3715 programmatic comparisons. 3717 If any vendor-specific PA-TNC attribute types or future IETF 3718 Standard PA-TNC Attribute Types include strings that are 3719 intended for display to a user, they should be translated to the 3720 user's preferred language. The Posture Broker Server will need 3721 to expose the user's preferences to the Posture Validators 3722 through whatever API or protocol is used to connect those 3723 components. However, that is all out of scope for this 3724 specification. 3726 B.10. Evaluation Against Requirements C-10 3728 Requirement C-10 says: 3730 C-10 NEA protocols MUST support encoding of strings in UTF-8 3731 format. 3733 PA-TNC meets this requirement. All strings in the PA-TNC 3734 protocol are encoded in UTF-8 format. This allows the protocol 3735 to support a wide range of languages efficiently. 3737 B.11. Evaluation Against Requirements C-11 3739 Requirement C-11 says: 3741 C-11 Due to the potentially different transport characteristics 3742 provided by the underlying candidate PT protocols, the NEA 3743 Client and NEA Server MUST be capable of becoming aware of and 3744 adapting to the limitations of the available PT protocol. For 3745 example, some PT protocol characteristics that might impact the 3746 operation of PA and PB include restrictions on: which end can 3747 initiate a NEA connection, maximum data size in a message or 3748 full assessment, upper bound on number of roundtrips, and 3749 ordering (duplex) of messages exchanged. The selection process 3750 for the PT protocols MUST consider the limitations the candidate 3751 PT protocol would impose upon the PA and PB protocols. 3753 PA-TNC meets this requirement. The design of the PA-TNC 3754 protocol emphasizes efficient transport of information in order 3755 to maximize its usability in constrained PT environments. Local 3756 APIs could allow Posture Collectors and Posture Validators to 3757 discover when they are operating in a less constrained 3758 deployment and then make use of more verbose attributes. 3759 Similarly, Posture Collectors could choose to not send or use 3760 smaller attributes (including assertions from previous 3761 assessments) when faced with a very constrained network 3762 connection. 3764 B.12. Evaluation Against Requirements PA-1 3766 Requirement PA-1 says: 3768 PA-1 The PA protocol MUST support communication of an 3769 extensible set of NEA standards defined attributes. These 3770 attributes will be uniquely identifiable from non-standard 3771 attributes. 3773 PA-TNC meets this requirement. Each attribute is identified 3774 with a PA-TNC Attribute Vendor ID and a PA-TNC Attribute Type. 3775 IETF Standard PA-TNC Attribute Types use a vendor ID of zero 3776 (0), in contrast with vendor-specific PA-TNC Attribute Types, 3777 which will use the vendor's SMI Private Enterprise Number as the 3778 vendor ID. The IANA will maintain a registry of PA-TNC 3779 Attribute Types with new values added by Expert Review with 3780 Specification Required, as described in the IANA Considerations 3781 section of this specification. Thus, the set of standard 3782 attribute types is extensible, but all standard attribute types 3783 are uniquely identifiable. 3785 B.13. Evaluation Against Requirements PA-2 3787 Requirement PA-2 says: 3789 PA-2 The PA protocol MUST support communication of an 3790 extensible set of vendor-specific attributes. These attributes 3791 will be segmented into uniquely identifiable vendor specific 3792 name spaces. 3794 PA-TNC meets this requirement. Each attribute is identified 3795 with a PA-TNC Attribute Vendor ID and a PA-TNC Attribute Type. 3796 Vendor-defined PA-TNC Attribute Types use the vendor's SMI 3797 Private Enterprise Number as the PA-TNC Attribute Vendor ID. 3798 Each vendor can define up to 2^32 PA-TNC Attribute Types, using 3799 its own internal processes to manage its set of attribute types. 3801 The IANA is not involved, other than the initial assignment of 3802 the vendor's SMI Private Enterprise Number. Thus, the set of 3803 vendor-specific attributes is segmented into uniquely 3804 identifiable vendor-specific name spaces. 3806 B.14. Evaluation Against Requirements PA-3 3808 Requirement PA-3 says: 3810 PA-3 The PA protocol MUST enable a Posture Validator to make 3811 one or more requests for attributes from a Posture Collector 3812 within a single assessment. This enables the Posture Validator 3813 to reassess the posture of a particular endpoint feature or to 3814 request additional posture including from other parts of the 3815 endpoint. 3817 PA-TNC meets this requirement. The Attribute Request attribute 3818 type is an IETF Standard PA-TNC Attribute Type that permits a 3819 Posture Validator to send to one or more Posture Collectors a 3820 request for one or more attributes. This attribute may be sent 3821 at any point in the posture assessment process and may in fact 3822 be sent more than once if the Posture Validator needs to first 3823 determine the type of operating system and then request certain 3824 attributes specific to that operating system, for example. 3826 B.15. Evaluation Against Requirements PA-4 3828 Requirement PA-4 says: 3830 PA-4 The PA protocol MUST be capable of returning attributes 3831 from a Posture Validator to a Posture Collector. For example, 3832 this might enable the Posture Collector to learn the specific 3833 reason for a failed assessment and to aid in remediation and 3834 notification of the system owner. 3836 PA-TNC meets this requirement. A Posture Validator can easily 3837 send attributes to one or more Posture Collectors. 3839 B.16. Evaluation Against Requirements PA-5 3841 Requirement PA-5 says: 3843 PA-5 The PA protocol SHOULD provide authentication, integrity, 3844 and confidentiality of attributes communicated between a Posture 3845 Collector and Posture Validator. This enables end-to-end 3846 security across a NEA deployment that might involve traversal of 3847 several systems or trust boundaries. 3849 PA-TNC does not include an explicit PA-level security mechanism 3850 but does lay a foundation allowing attribute level security 3851 protections to be added later. As an existence proof, the NEA 3852 working group considered an internet draft proposal capable of 3853 encapsulating PA attributes within a CMS security wrapper in a 3854 new attribute type. This proposal offered the protections 3855 described in this requirement. However the NEA WG decided that 3856 the use cases in scope for the working group did not require PA- 3857 level security. The use cases involving PA message traversal of 3858 multiple systems or trust boundaries were considered out of 3859 scope, therefore a Posture Validator to Posture Collector end- 3860 to-end security protection was considered to not be required. 3862 Instead PA-TNC attributes are protected by the PT layer 3863 authentication, integrity and confidentiality support. This 3864 protects the attributes communicated between the Posture 3865 Transport Client and Posture Transport Server. Because the 3866 Posture Collector is in the same address space as the Posture 3867 Broker Client and Posture Transport Client and the Posture 3868 Validator is in the same address space as the Posture Broker 3869 Server and Posture Transport Server, the underlying broker and 3870 transport components are deemed trusted with respect to not 3871 tampering with the PA messages (see trust model in section 5.1 3872 for details.) Encrypting the PA-TNC messages would not prevent 3873 a hostile broker or transport component from attacking the 3874 messages. 3876 B.17. Evaluation Against Requirements PA-6 3878 Requirement PA-6 says: 3880 PA-6 The PA protocol MUST be capable of carrying attributes 3881 that contain non-binary and binary data including encrypted 3882 content. 3884 PA-TNC meets this requirement. PA-TNC attributes can contain 3885 non-binary and binary data including encrypted content. For 3886 examples, see the attribute type definitions contained in this 3887 specification. 3889 Authors' Addresses 3891 Paul Sangster 3892 Symantec Corporation 3893 6825 Citrine Drive 3894 Carlsbad, CA 92009 USA 3895 Email: Paul_Sangster@symantec.com 3897 Kaushik Narayan 3898 Cisco Systems Inc. 3899 10 West Tasman Drive 3900 San Jose, CA 95134 3901 Email: kaushik@cisco.com