idnits 2.17.1 draft-sangster-nea-pa-tnc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2613. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2589. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2596. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2602. 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 3 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 18, 2008) is 5910 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 2434 (ref. '3') (Obsoleted by RFC 5226) -- No information found for draft-sahita-nea-pb - is the name correct? -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-07) exists of draft-ietf-nea-requirements-05 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 9 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 5 Expires: August 2008 7 February 18, 2008 9 PA-TNC: A Posture Attribute Protocol (PA) Compatible with TNC 10 draft-sangster-nea-pa-tnc-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that 15 any applicable patent or other IPR claims of which he or she is 16 aware have been or will be disclosed, and any of which he or she 17 becomes aware will be disclosed, in accordance with Section 6 of 18 BCP 79. 20 Internet-Drafts are working documents of the Internet 21 Engineering Task Force (IETF), its areas, and its working 22 groups. Note that other groups may also distribute working 23 documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet- 28 Drafts as reference material or to cite them other than as "work 29 in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on August 7, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 This document specifies PA-TNC, a Posture Attribute Protocol 46 identical to the Trusted Computing Group's IF-M 1.0 protocol. 47 The document then evaluates PA-TNC against the requirements 48 defined in the NEA Requirements specification. 50 Conventions used in this document 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 53 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 54 "OPTIONAL" in this document are to be interpreted as described 55 in RFC 2119 [1]. 57 Table of Contents 59 1. Introduction...............................................3 60 1.1. Background on Trusted Computing Group.................3 61 1.2. Background on Trusted Network Connect.................4 62 1.3. Submission of This Document...........................4 63 1.4. Prerequisites.........................................4 64 1.5. Message Diagram Conventions...........................5 65 2. PA-TNC Message Protocol....................................5 66 2.1. PA-TNC Messaging Model................................5 67 2.2. PA-TNC Relationship to PB-TNC.........................6 68 2.3. PA-TNC Messages in PB-TNC.............................9 69 2.4. IETF Standard PA Subtypes.............................9 70 2.5. PA-TNC Message Header Format.........................10 71 3. PA-TNC Attributes.........................................12 72 3.1. PA-TNC Attribute Header..............................12 73 3.2. IETF Standard PA-TNC Attribute Types.................16 74 3.2.1. Attribute Request...............................18 75 3.2.2. Product Information.............................20 76 3.2.3. Numeric Version.................................22 77 3.2.4. String Version..................................24 78 3.2.5. Operational Status..............................27 79 3.2.6. Port Filter.....................................30 80 3.2.7. Installed Packages..............................32 81 3.2.8. PA-TNC Error....................................35 82 3.2.8.1. Definition of Invalid Parameter Error Code.38 83 3.2.8.2. Definition of Version Not Supported Error 84 Code.......................................39 85 3.2.8.3. Definition of Attribute Type Not Supported 86 Error Code.................................41 87 3.3. Vendor-Defined Attributes............................43 88 4. Evaluation Against NEA Requirements.......................43 89 4.1. Evaluation Against Requirement C-1...................44 90 4.2. Evaluation Against Requirement C-2...................44 91 4.3. Evaluation Against Requirement C-3...................44 92 4.4. Evaluation Against Requirement C-4...................44 93 4.5. Evaluation Against Requirement C-5...................45 94 4.6. Evaluation Against Requirement C-6...................45 95 4.7. Evaluation Against Requirement C-7...................46 96 4.8. Evaluation Against Requirement C-8...................46 97 4.9. Evaluation Against Requirement C-9...................46 98 4.10. Evaluation Against Requirement C-10.................47 99 4.11. Evaluation Against Requirement PA-1.................47 100 4.12. Evaluation Against Requirement PA-2.................48 101 4.13. Evaluation Against Requirement PA-3.................48 102 4.14. Evaluation Against Requirement PA-4.................48 103 4.15. Evaluation Against Requirement PA-5.................49 104 4.16. Evaluation Against Requirement PA-6.................49 105 5. Security Considerations...................................50 106 5.1. Trust Relationships..................................50 107 5.1.1. Posture Collector...............................50 108 5.1.2. Posture Validator...............................51 109 5.1.3. Posture Broker Client, Posture Broker Server, 110 and PB-TNC......................................51 111 5.2. Security Threats.....................................52 112 5.2.1. Attribute Theft.................................52 113 5.2.2. Message Fabrication.............................53 114 5.2.3. Attribute Modification..........................53 115 5.2.4. Attribute Replay................................53 116 5.2.5. Attribute Insertion.............................54 117 5.2.6. Denial of Service...............................54 118 6. Privacy Considerations....................................55 119 7. IANA Considerations.......................................56 120 7.1. New IETF Standard PA Subtypes........................56 121 7.2. Registry for IETF Standard PA-TNC Attribute Types....57 122 7.3. Registry for IETF Standard PA-TNC Error Codes........58 123 8. Acknowledgments...........................................59 124 9. References................................................59 125 9.1. Normative References.................................59 126 9.2. Informative References...............................59 127 Author's Address.............................................60 128 Intellectual Property Statement..............................60 129 Disclaimer of Validity.......................................61 131 1. Introduction 133 This document specifies PA-TNC, a Posture Attribute Protocol 134 (PA) identical to the Trusted Computing Group's IF-M 1.0 135 protocol [6]. The document then evaluates PA-TNC against the 136 requirements defined in the NEA Requirements specification [7]. 138 1.1. Background on Trusted Computing Group 140 The Trusted Computing Group (TCG) is a consortium that develops 141 specifications for trusted (secure) computing. Since its 142 formation in 2003, TCG has published specifications for a 143 variety of technologies such as Trusted Platform Module (TPM), 144 TCG Software Stack (TSS), Mobile Trusted Module (MTM), and 145 Trusted Network Connect (TNC). 147 TCG members include more than 175 organizations that design, 148 build, sell, or use trusted computing technology. Membership is 149 open to any organization that signs the membership agreement and 150 pays the annual membership fee. Non-members are welcome to 151 implement the TCG specifications. Several open source 152 implementers have done so. 154 1.2. Background on Trusted Network Connect 156 Starting in 2004, the TCG has defined and published the Trusted 157 Network Connect (TNC) architecture and standards for network 158 access control. These standards enable multi-vendor 159 interoperability at all points in the architecture and have been 160 widely adopted and deployed. 162 1.3. Submission of This Document 164 The IETF has recently chartered the Network Endpoint Assessment 165 (NEA) working group to develop several standards in the same 166 area as TNC. In order to avoid the development of multiple 167 incompatible standards, the TCG is offering several of its TNC 168 standards to the IETF as candidates for standardization in the 169 IETF also. This document is equivalent to TCG's IF-M 1.0. 171 Consistent with IETF's requirements for standards track 172 documents, the TCG has authorized the editors of this document 173 to offer the specification to the IETF without restriction. As 174 with other Internet-Drafts, the IETF Trust owns the copyright to 175 this document. The IETF may modify this document, ignore it, 176 publish it as an RFC, or take any other action. If the IETF 177 decides to adopt a later version of this document as an RFC, the 178 TCG plans to publish a specification for an equivalent TNC 179 protocol to ensure compatibility. 181 1.4. Prerequisites 183 This document does not define an architecture or reference 184 model. Instead, it defines a protocol that works within the 185 reference model described in the NEA Requirements specification. 186 The reader is assumed to be thoroughly familiar with that 187 document. No familiarity with TCG specifications is assumed. 189 1.5. Message Diagram Conventions 191 This specification defines the syntax of PA-TNC messages using 192 diagrams. Each diagram depicts the format and size of each 193 field in bits. Implementations MUST send the bits in each 194 diagram as they are shown, traversing the diagram from top to 195 bottom and then from left to right within each line (which 196 represents a 32-bit quantity). Multi-byte fields representing 197 numeric values must be sent in network (big endian) byte order. 199 Descriptions of bit field (e.g. flag) values are described 200 referring to the position of the bit within the field. These 201 bit positions are numbered from the most significant bit through 202 the least significant bit so a one octet field with only bit 0 203 set has the value 0x80. 205 2. PA-TNC Message Protocol 207 This section discusses the use of the PA-TNC message and its 208 attributes, and specifies the syntax and semantics for the PA- 209 TNC message header. The details of each attribute included 210 within the PA-TNC payload are specified in section 3.2. 212 2.1. PA-TNC Messaging Model 214 PA-TNC messages are carried by the PB-TNC protocol [5], which 215 provides a multi-roundtrip reliable transport and end-to-end 216 message delivery to subscribed (interested) parties using a 217 variety of underlying network protocols. PA-TNC is unaware of 218 these underlying PT transport protocols being used below PB-TNC. 219 The interested parties consist of Posture Collectors on the NEA 220 Client and Posture Validators associated with the NEA Server 221 that have registered to receive messages about particular types 222 of components (e.g. anti-virus) during an assessment. The PA- 223 TNC messaging protocol operates synchronously within an 224 assessment session, with Posture Collectors and Posture 225 Validators taking turns sending one or more messages to each 226 other. Each PA-TNC message may contain one or more attributes 227 associated with the functional component defined in the PB 228 protocol. Posture Collectors may only send PA-TNC messages to 229 Posture Validators and vice versa. No Posture Collector to 230 Posture Collector or Posture Validator to Posture Validator 231 messaging is allowed to occur. Each Posture Collector or 232 Posture Validator may send several PA-TNC messages in succession 233 before indicating that it has completed its response to the 234 Posture Broker Client or Posture Broker Server respectively. As 235 necessary, the Posture Broker Client and Posture Broker Server 236 will batch these messages prior to sending them over the 237 network. 239 PB-TNC provides a publish/subscribe model of message exchange. 240 This means that, at any given point in time, zero or more 241 subscribers for a particular type of message may be present on a 242 Posture Broker Client or Posture Broker Server. This is 243 beneficial, since it allows one Posture Collector or Posture 244 Validator to combine multiple functions (like anti-virus and 245 personal firewall) by subscribing to both TNC standard component 246 types. It also allows multiple Posture Collectors or Posture 247 Validators to support the same components, such as two anti- 248 virus Posture Validators that are each used to manage their own 249 respective anti-virus client software. However, this 250 publish/subscribe model has some possible negative side effects. 251 When a Posture Collector or Posture Validator initially sends a 252 PA-TNC message, it does not know whether it will receive many, 253 one, or no PA-TNC messages from the other side. For many types 254 of assessments, this is acceptable, but in some cases a more 255 direct channel binding between a particular Posture Collector 256 and Posture Validator pair is necessary. For example, a Posture 257 Validator may wish to provide remediation instructions to a 258 particular Posture Collector that it knows is capable of 259 remediating a non-compliant component. This can be accomplished 260 using the PB-TNC capability to limit distribution of a message 261 to a single Posture Collector. 263 2.2. PA-TNC Relationship to PB-TNC 265 This section summarizes the major elements of a PA-TNC message 266 as they might appear inside of a PB-TNC message. The double 267 line (===) in the diagram below indicates the separation between 268 the PB-TNC and PA-TNC protocols. The PA-TNC portion of the 269 message is delivered to each Posture Collector or Posture 270 Validator registered to receive messages containing a particular 271 message type. Note that PB-TNC is capable of carrying multiple 272 PB-TNC and PA-TNC messages in a single PB-TNC batch. See the 273 PB-TNC specification [5] for more information on its 274 capabilities. 276 One important linkage between the PA-TNC and PB-TNC protocols is 277 the PA message type (PA Message Vendor ID and PA subtype) that 278 is used by the Posture Broker Client and Posture Broker Server 279 to route messages to interested Posture Collectors and Posture 280 Validators. The message type indicates the software component 281 (component type) that is associated with the attributes included 282 inside the PA-TNC message. Therefore, Posture Collectors and 283 Posture Validators written to support an assessment of a 284 particular component can register to receive messages about the 285 component and thus participate in its assessment. Each Posture 286 Collector and Posture Validator MUST only send PA-TNC messages 287 containing attributes that pertain to the software component 288 defined in the message type of the message. This assures that 289 only the appropriate Posture Collectors and Posture Validators 290 that support a particular type of component will receive 291 attributes related to that component. If a PA-TNC message 292 contained a mix of attributes about different components and a 293 message type of only one of those components, the message would 294 only be delivered to parties interested in the component type 295 included in the message type, so other interested recipients 296 wouldn't see those attributes. 298 The message type is comprised of 2 fields: a PA Message Vendor 299 ID and a PA Subtype. The PA Message Vendor ID identifies the 300 vendor or other organization that defined this message type. The 301 PA Subtype identifies the message type more particularly within 302 the set of message types defined by that vendor. This 303 specification defines several IETF Standard PA Subtypes to be 304 used with a PA Message Vendor ID of zero (0). Within this 305 specification, the PA Subtype field is used to indicate the type 306 of component (e.g. firewall) involved with the message's 307 attributes. Therefore for clarity the PA subtype will be 308 referred to as the "component type" in this specification. 309 Vendor-defined name spaces may use other semantics for the PA 310 Subtype field as this is outside the scope of this 311 specification. 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | PB-TNC Header | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | PB-TNC Message of type PB-PA-Message | 317 | (includes PA Message Vendor ID, PA Subtype, and other fields | 318 | used by Posture Broker Client and Posture Broker Server for | 319 | routing) | 320 ================================================================= 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | PA-TNC Message Header | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | PA-TNC Attribute | 325 | (e.g. Product Information) | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | PA-TNC Attribute | 328 | (e.g. Operational Status) | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Figure 1 Overview of a PB-TNC batch that contains a PA-TNC 332 Message 334 For example, if a Posture Broker Client sent a PB-TNC batch that 335 contained a PA-TNC message with a message type indicating 336 firewall component, this message would be routed by the Posture 337 Broker Server to Posture Validators registered to assess 338 firewalls. Each registered Posture Validator would receive a 339 copy of the PA-TNC message including the PA-TNC header and set 340 of attributes. It is important that each of the attributes 341 included in the PA-TNC message be associated with the firewall 342 component because only the Posture Collector and Posture 343 Validator interested in firewalls will receive such messages. 344 For example, if the above message contained both firewall and 345 operating system attributes (inside a PA-TNC message with a 346 component type of firewall), then any Posture Collector and 347 Posture Validator registered to receive operating system 348 messages would not receive those attributes, as the messages 349 would only be delivered to those registered for firewall 350 messages. 352 2.3. PA-TNC Messages in PB-TNC 354 As depicted in section 2.2, a PA-TNC message consists of a PA- 355 TNC header followed by a sequence of one or more attributes. The 356 PA-TNC message header (described in section 2.5) and the header 357 for each of the PA-TNC attributes (specified in section 3.1) 358 have a fixed type-length-value (TLV) format. Each PA-TNC 359 message MAY contain a mixture of standards-based and vendor- 360 defined attributes identifiable using the type portion of the 361 attribute header. All Posture Collectors and Posture Validators 362 compliant with this specification MUST be capable of processing 363 multiple attributes in a received PA-TNC message. A Posture 364 Collector or Posture Validator that receives a PA-TNC message 365 can use the attribute header's length field to skip any 366 attributes that it does not understand, unless the attribute is 367 marked as mandatory to process. 369 2.4. IETF Standard PA Subtypes 371 This section defines several IETF Standard PA Subtypes. Each PA 372 subtype defined here identifies a specific component relevant to 373 the endpoint's posture. This allows a small set of generic PA- 374 TNC attributes (e.g. Product Information) to be used to describe 375 a large number of different components (e.g. OS, anti-virus 376 software, etc.). It also allows Posture Collectors and Posture 377 Validators to specialize in a particular component (e.g. 378 operating system) and only receive PA-TNC messages relevant to 379 that component. 381 Number Name Definition 382 ------ ---- ---------- 383 0 Testing Reserved for use in specification 384 examples, experimentation and 385 testing. 387 1 Operating System Operating system running on the 388 endpoint 390 2 Anti-Virus Host-based anti-virus software 392 3 Anti-Spyware Host-based anti-spyware software 394 4 Anti-Malware Host-based anti-malware (e.g. anti- 395 bot) software not included within 396 anti-virus or anti-spyware components 398 5 Firewall Host-based firewall 400 6 IDPS Host-based Intrusion Detection and/or 401 Prevention Software (IDPS) 403 7 VPN Host-based Virtual Private Networking 404 (VPN) software 406 These PA subtypes must be used in a PB-PA message with a PA 407 Message Vendor ID of zero (0) (as described in the PB-TNC 408 specification [5]). If these PA subtype values are used with a 409 different PA Message Vendor ID, they have a completely different 410 meaning that is not defined in this specification. 412 2.5. PA-TNC Message Header Format 414 This section describes the format and semantics of the PA-TNC 415 header. Every PA-TNC message MUST start with a PA-TNC header. 416 The PA-TNC header provides a common context applying to all of 417 the attributes contained within the PA-TNC payload. The payload 418 consists of a sequence of assessment attributes described in 419 section 3. 421 1 2 3 422 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 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Version | Reserved | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Message Identifier | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 Version 430 This field indicates the version of the format for the PA-TNC 431 message. This version is intended to allow for evolution of 432 the PA-TNC message header and payload in a manner that can 433 easily be detected by message recipients. 435 PA-TNC message senders MUST set this field to 0x01 for all 436 PA-TNC messages that comply with formats and requirements 437 described in version 1.0 of this specification. 438 Implementations responding to a PA-TNC message containing a 439 supported version SHOULD use the same Version number to 440 minimize the risk of version incompatibility. 442 Message senders MAY send an empty PA-TNC message with the 443 Version value set to 0 in order to discover the PA-TNC 444 protocol versions supported by peer recipients (see PA-TNC 445 Error Code information in section 3.2.8). Message recipients 446 MUST NOT support version 0 and MUST NOT interpret the 447 contents (after the Version field) of a PA-TNC message 448 containing a version number that the recipient does not 449 support. Message recipients MUST respond to a PA-TNC message 450 with an unsupported version by sending a Version Not 451 Supported error code in a PA-TNC Error attribute. 453 PA-TNC message initiators supporting multiple PA-TNC protocol 454 versions SHOULD be able to alter which version of PA-TNC 455 message they send based on prior message exchanges with a 456 particular peer Posture Collector or Posture Validator. 458 Reserved 460 Reserved for future use. This field MUST be set to 0 on 461 transmission and ignored upon reception. 463 Message Identifier 465 This field contains a value that uniquely identifies this 466 message, differentiating it from others sent by a particular 467 PA-TNC message sender within this assessment. This value can 468 be included in a response message to indicate which message 469 was received and caused the response. For example, this 470 field is included in the PA-TNC error messages so the party 471 who receives the error message can determine which of the 472 messages they had sent caused the error. 474 PA-TNC message senders MUST NOT send the same message 475 identifier more than once during an assessment. Message 476 identifiers may be randomly generated or sequenced as long as 477 values are not repeated during an assessment message 478 exchange. PA-TNC message recipients are not required to 479 check for duplicate message identifiers. 481 3. PA-TNC Attributes 483 This section defines the PA-TNC attributes that can be carried 484 within a PA-TNC message. The initial section defines the 485 standard attribute header that appears at the start of each 486 attribute in a PA-TNC message. The second section defines each 487 of the IETF Standard PA-TNC attributes and the final section 488 discusses how vendor-defined PA-TNC attributes can be used 489 within a PA-TNC message. Vendor-defined PA-TNC attributes use 490 the vendor's SMI Private Enterprise Number in the Attribute Type 491 field. 493 A PA-TNC message MUST contain a PA-TNC header (defined in 494 section 2.5) followed by a sequence of zero or more PA-TNC 495 attributes. All PA-TNC attributes MUST begin with a standard PA- 496 TNC attribute header, as defined in section 3.1. The contents 497 of PA-TNC attributes vary widely, depending on their attribute 498 type. Section 3.2 defines the IETF Standard PA-TNC Attributes. 499 Section 3.3 discusses how vendor-specific PA-TNC attributes can 500 be defined. 502 3.1. PA-TNC Attribute Header 504 Following the PA-TNC message header is a sequence of zero or 505 more attributes. All PA-TNC attributes MUST begin with the 506 standard PA-TNC attribute header defined in this subsection. 507 Each attribute described in this specification is represented by 508 a TLV tuple. The TLV tuple includes an attribute identifier 509 comprised of the Vendor ID and Attribute Type (type), the TLV 510 tuple's overall length and finally the attribute's value. The 511 use of TLV representation was chosen due to its flexibility and 512 extensibility and use in other standards. Recipients of an 513 attribute can use the attribute type fields to determine the 514 precise syntax and semantics of the attribute value field and 515 the length to skip over an unrecognized attribute. The length 516 field is also beneficial when a variable length attribute value 517 is provided. 519 The TLV format does not contain an explicit TLV format version 520 number, so every attribute included in a particular PA-TNC 521 message MUST use the same TLV format. Using the PA-TNC message 522 version number to indicate the format of all TLV attributes 523 within a PA-TNC message allows for future versioning of the TLV 524 format in a manner detectable by PA-TNC message recipients. 525 Similarly, requiring all TLV attribute formats to be the same 526 within a PA-TNC message also assures that recipients compliant 527 with a particular PA-TNC message version can at least parse 528 every attribute header and use the length to skip over 529 unrecognized attributes. Every PA-TNC 1.0 compliant TLV 530 attribute MUST use the following TLV format: 532 1 2 3 533 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 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Flags | PA-TNC Attribute Vendor ID | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | PA-TNC Attribute Type | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | PA-TNC Attribute Length | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Correlation ID | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Attribute Value (Variable Length) | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 Flags 548 This field defines flags impacting the processing of the 549 associated attribute. 551 Bit 0 (0x80) is the NOSKIP flag. Any Posture Collector or 552 Posture Validator that receives an attribute with this flag 553 set to 1 but does not support this attribute MUST NOT process 554 any part of the PA-TNC message and SHOULD respond with an 555 Attribute Type Not Supported error in a PA-TNC error message. 557 In order to avoid taking action on a subset of the attributes 558 only to later find an unsupported attribute with the NOSKIP 559 flag set, recipients of a multi-attribute PA-TNC message 560 might need to scan all of the attributes prior to acting upon 561 any attribute. 563 When the NOSKIP flag is set to 0, recipients SHOULD skip any 564 unsupported attributes and continue processing the next 565 attribute. 567 Bit 1 (0x40) is the Correlation ID (COR) flag. This flag 568 indicates whether the optional Correlation ID value is 569 included in the header. When set to 1, a 32 bit Correlation 570 ID field is present. Otherwise when set to 0, no Correlation 571 ID is included. 573 Bit 2-7 are reserved for future use. These bits MUST be set 574 to 0 on transmission and ignored upon reception. 576 PA-TNC Attribute Vendor ID 578 This field indicates the owner of the name space associated 579 with the PA-TNC Attribute Type. This is accomplished by 580 specifying the 24 bit SMI Private Enterprise Number Vendor ID 581 of the party who owns the Attribute Type name space. IETF 582 Standard PA-TNC Attribute Types MUST use zero (0) in this 583 field. 585 The PA-TNC Attribute Vendor ID 0xffffff is reserved. Posture 586 Collectors and Posture Verifiers MUST NOT send PA-TNC 587 messages in which the PA-TNC Attribute Vendor ID has this 588 reserved value (0xffffff). If a Posture Collector or Posture 589 Verifier receives a message in which the PA-TNC Attribute 590 Vendor ID has this reserved value (0xffffff), it SHOULD 591 respond with an Invalid Parameter error code in a PA-TNC 592 Error attribute. 594 PA-TNC Attribute Type 596 This field defines the type of the attribute included in the 597 Attribute Value field. This field is qualified by the PA-TNC 598 Attribute Vendor ID field so that a particular PA-TNC 599 Attribute Type value (e.g. 327) has a completely different 600 meaning depending on the value in the PA-TNC Attribute Vendor 601 ID field. 603 If the PA-TNC Attribute Vendor ID field has the value zero 604 (0) then the PA-TNC Attribute Type field contains an IETF 605 Standard PA-TNC Attribute Type, as listed in the IANA 606 registry. Section 3.2 of this specification defines the 607 initial set of IETF Standard PA-TNC Attribute Types. 609 The PA-TNC Attribute Type 0xffffffff is reserved. Posture 610 Collectors and Posture Verifiers MUST NOT send PA-TNC 611 messages in which the PA-TNC Attribute Type has this reserved 612 value (0xffffffff). If a Posture Collector or Posture 613 Verifier receives a message in which the PA-TNC Attribute 614 Type has this reserved value (0xffffffff), it SHOULD respond 615 with an Invalid Parameter error code in a PA-TNC Error 616 attribute. 618 PA-TNC Attribute Length 620 This field contains the length in octets of the entire PA-TNC 621 Attribute including the PA-TNC Attribute Header (the fields 622 Flags, PA-TNC Attribute Vendor ID, PA-TNC Attribute Type, and 623 PA-TNC Attribute Length). Therefore, this value MUST always 624 be at least 12 (16 if the Correlation ID is present). Any 625 Posture Collector or Posture Verifier that receives a message 626 with a PA-TNC Attribute Length field whose value is less than 627 12 (16 if the Correlation ID is present) SHOULD respond with 628 an Invalid Parameter PA-TNC error code. 630 Implementations that do not support the specified PA-TNC 631 Attribute Type can use this length to skip over this 632 attribute to the next attribute. Note that while this field 633 is 4 octets the maximum usable attribute length is likely to 634 be less than 2^32-1 due to limitations of the underlying 635 protocol stack. 637 Correlation ID 639 This optional field MUST be present when the COR flag is set 640 to 1 and MUST NOT be present when the COR flag is set to 0. 641 Normally, this field will not be present. However, there are 642 times when this field is necessary. 644 Some Posture Collectors may wish to report on several 645 products with the same component ID on an endpoint (e.g. two 646 anti-malware software packages). In this case, the Posture 647 Collector and Posture Validator need a way to identify the 648 different products. For example, if a Posture Validator 649 requests Product Information and Numeric Version attributes 650 for the anti-malware component, this Posture Collector would 651 produce two Product Information and two Numeric Version 652 attributes, each attribute having a Correlation ID specific 653 to the product being described. The Product Information and 654 Numeric Version attributes describing the same product would 655 have the same Correlation ID. This allows the Posture 656 Validator to associate the Product Information and Numeric 657 Version attributes that apply to a single product. Because 658 the Product Information and Numeric Version attribute 659 requests might be requested at different times, it is 660 important that the Posture Collector use a consistent value 661 for each product upon which it is able to report. A Posture 662 Collector might create a persistent table of locally unique 663 IDs (e.g. counters) for each product upon which it reports, 664 for situations where a Correlation ID is necessary. 666 Note that many Posture Collectors will not need to worry 667 about Correlation IDs because they will only support 668 reporting on one product per endpoint. If an endpoint has two 669 anti-malware Posture Collectors installed that each support 670 only one product and those Posture Collectors are reporting 671 on two separate anti-malware products, the Correlation ID is 672 not required. This is because the Posture Validator can use 673 the Posture Collector ID reported in the PB-TNC protocol to 674 associate the attributes sent by each Posture Collector. 676 When a single Posture Collector needs to send several 677 attributes in a single assessment that pertain to separate 678 products but have the same PA Message Vendor ID and PA 679 Subtype, the Posture Collector MUST use the Correlation ID 680 field. The Correlation ID value MUST be constant per product 681 for an entire PB-TNC session so that the Posture Validator 682 can correlate attributes requested earlier about the same 683 product. The Posture Validator MAY send attributes with a 684 Correlation ID to identify the product to which they pertain. 686 Attribute Value 688 This field varies depending on the particular type of 689 attribute being expressed. The contents of this field for 690 each of the IETF Standard PA-TNC Attribute Types is defined 691 in section 3.2. 693 3.2. IETF Standard PA-TNC Attribute Types 695 This section defines an initial set of IETF Standard PA-TNC 696 Attribute Types. These Attribute Types MUST always be used with 697 a PA-TNC Vendor ID of zero (0). If these PA-TNC Attribute Type 698 values are used with a different PA-TNC Vendor ID, they have a 699 completely different meaning that is not defined in this 700 specification. 702 The following table briefly describes each attribute and defines 703 the numeric value to be used in the PA-TNC Attribute Type field 704 of the PA-TNC Attribute Header. Later subsections provide 705 detailed specifications for each PA-TNC Attribute Value. 707 Number Name Description 708 ------ ---- ----------- 709 0 Testing Reserved for use in 710 specification examples, 711 experimentation and testing. 713 1 Attribute Request Contains a list of attribute 714 type values defining the 715 attributes desired from the 716 Posture Collectors. 718 2 Product Information Manufacturer and product 719 information for the component. 721 3 Numeric Version Numeric version of the 722 component. 724 4 String Version String version of the 725 component. 727 5 Operational Status Describes whether the component 728 is running on the endpoint. 730 6 Port Filter Lists the set of ports (e.g. 731 TCP port 80 for HTTP) that are 732 allowed or blocked on the 733 endpoint. 735 7 Installed Packages List of software packages 736 installed on endpoint that 737 provide the requested 738 component. 740 8 PA-TNC Error PA-TNC message or attribute 741 processing error. 743 The following subsections discuss the usage, format and 744 semantics of the Attribute Value field for each IETF Standard 745 PA-TNC Attribute Type. 747 3.2.1. Attribute Request 749 This PA-TNC Attribute Type allows a Posture Validator to request 750 certain attributes from the registered set of Posture 751 Collectors. 753 All Posture Collectors that implement any of the IETF Standard 754 PA Subtypes defined in this specification SHOULD support 755 receiving and processing this attribute type for at least those 756 PA subtypes. Posture Collectors that receive and process this 757 attribute MAY choose to send all, a subset or none of the 758 requested attributes but MUST NOT send attributes that were not 759 requested (except error attributes). All Posture Validators 760 that implement any of the IETF Standard PA Subtypes defined in 761 this specification SHOULD support sending this attribute type 762 for at least those PA subtypes. 764 Posture Verifiers MUST NOT include this attribute type in an 765 Attribute Request attribute. It does not make sense for a 766 Posture Verifier to request that a Posture Collector send an 767 Attribute Request attribute. 769 For this attribute type, the PA-TNC Attribute Vendor ID field 770 MUST be set to zero (0) and the PA-TNC Attribute Type field MUST 771 be set to 1. 773 The following diagram illustrates the format and contents of the 774 Attribute Value field for this attribute type. The text after 775 this diagram describes the fields shown here. 777 Note that this diagram shows two attribute types. The actual 778 number of attribute types included in an Attribute Request 779 attribute can vary from one to a large number (limited only by 780 the maximum message and length supported by the underlying PT 781 transport protocol). However, each Attribute Request MUST 782 contain at least one attribute type. Because the length of a 783 PA-TNC Attribute Vendor ID paired with a PA-TNC Attribute Type 784 and a one octet Reserved field is always 8 octets, the number of 785 requested attributes can be easily computed using the PA-TNC 786 Attribute Length field by subtracting the number of octets in 787 the PA-TNC Attribute Header and dividing by 8. If the PA-TNC 788 Attribute Length field is invalid, Posture Collectors SHOULD 789 respond with an Invalid Parameter PA-TNC error code. 791 1 2 3 792 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 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Reserved | PA-TNC Attribute Vendor ID | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | PA-TNC Attribute Type | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Reserved | PA-TNC Attribute Vendor ID | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | PA-TNC Attribute Type | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 Reserved 805 Reserved for future use. This field MUST be set to 0 on 806 transmission and ignored upon reception. 808 PA-TNC Attribute Vendor ID 810 This field contains the SMI Private Enterprise Number of the 811 organization that controls the name space for the following 812 PA-TNC Attribute Type. This field enables IETF Standard PA- 813 TNC Attributes and vendor-defined PA-TNC Attributes to be 814 used without potential collisions. 816 Any IETF Standard PA-TNC Attribute Types defined in section 817 3.2 MUST use zero (0) in this field. Vendor-defined 818 attributes MUST use the SMI Private Enterprise Number of the 819 organization that defined the attribute. 821 PA-TNC Attribute Type 823 The PA-TNC Attribute Type field (together with the PA-TNC 824 Vendor ID field) indicates the specific attribute requested. 825 Some IETF Standard PA-TNC Attribute Types MUST NOT be 826 requested using this field (e.g. requesting a PA-TNC Error 827 attribute). This is explicitly indicated in the description 828 of those PA-TNC Attribute Types. Any Posture Collector or 829 Posture Validator that receives an Attribute Request 830 containing one of the prohibited Attribute Types SHOULD 831 respond with an Invalid Parameter error in a PA-TNC error 832 message. 834 3.2.2. Product Information 836 This PA-TNC Attribute Type contains identifying information 837 about a product that implements the component specified in the 838 PA Subtype field, as described in section 2.4. For example, if 839 the PA Subtype is Anti-Virus, this attribute would contain 840 information identifying an anti-virus product installed on the 841 endpoint. 843 All Posture Collectors that implement any of the IETF Standard 844 PA Subtypes defined in this specification MUST support sending 845 this attribute type, at least for those PA subtypes. Whether a 846 particular Posture Collector actually sends this attribute type 847 SHOULD still be governed by local privacy and security policies. 848 All Posture Validators that implement any of the IETF Standard 849 PA Subtypes defined in this specification MUST support receiving 850 this attribute type, at least for those PA subtypes. Posture 851 Validators MUST NOT send this attribute type. 853 For this attribute type, the PA-TNC Attribute Vendor ID field 854 MUST be set to zero (0) and the PA-TNC Attribute Type field MUST 855 be set to 2. The value in the PA-TNC Attribute Length field 856 will vary, depending on the length of the Product Name field. 857 However, the value in the PA-TNC Attribute Length field MUST be 858 at least 17 (21 if the Correlation ID field is present) because 859 this is the length of the fixed size fields in the PA-TNC 860 Attribute Header and the fixed size fields in this attribute 861 type. If the PA-TNC Attribute Length field is less than the 862 size of these fixed length fields, implementations SHOULD 863 respond with an Invalid Parameter PA-TNC error code. 865 This attribute type includes both numeric and textual 866 identifiers for the organization that created the product (the 867 "product creator") and for the product itself. For automated 868 processing, numeric identifiers are superior because they are 869 less ambiguous and more efficient. However, numeric identifiers 870 are only available if the product creator has assigned them. 871 Therefore, a textual identifier is also included. This textual 872 identifier has the additional benefit that it may be easier for 873 humans to read (although this benefit is minimal since the 874 primary purpose of this attribute is automated assessment). 876 The following diagram illustrates the format and contents of the 877 Attribute Value field for this attribute type. The text after 878 this diagram describes the fields shown here. 880 1 2 3 881 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 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | Product Vendor ID | Product ID | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | Product ID | Product Name (Variable Length) | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 Product Vendor ID 890 This field contains the SMI Private Enterprise Number for the 891 product creator. If the SMI PEN for the product creator is 892 unknown or if the product creator does not have an SMI PEN, 893 the Product Vendor ID field MUST be set to 0 and the identity 894 of the product creator SHOULD be included in the Product Name 895 along with the name of the product. 897 Product ID 899 This field identifies the product using a numeric identifier 900 assigned by the product creator. If this Product ID value is 901 unknown or if the product creator has not assigned such a 902 value, this field MUST be set to 0. If the Product Vendor ID 903 is 0, this field MUST be set to 0. In any case, the name of 904 the product SHOULD be included in the Product Name field. 906 Note that a particular Product ID value (e.g. 635) will have 907 completely different meanings depending on the Product Vendor 908 ID. Each Product Vendor ID defines a different space of 909 Product ID values. Product creators are encouraged to publish 910 lists of Product ID values for their products. 912 Product Name 914 This variable length field contains a UTF-8 [2] string 915 identifying the product (e.g. "Symantec Norton AntiVirus(TM) 916 2008") in enough detail to unambiguously distinguish it from 917 other products from the product creator. Products whose 918 creator is known, but does not have a registered SMI Private 919 Enterprise Number, SHOULD be represented using a combination 920 of the creator name and full product name (e.g. "Ubuntu(R) 921 IPtables" for the IPtables firewall in the Ubuntu 922 distribution of Linux). If the product creator's SMI Private 923 Enterprise Number is included in the Product Vendor ID field, 924 the product creator's name may be omitted from this field. 926 The length of this field can be determined by starting with 927 the value in the PA-TNC Attribute Length field in the PA-TNC 928 Attribute Header and subtracting the size of the fixed length 929 fields in that header (12 or 16, depending on whether the 930 Correlation ID is present) and the size of the fixed length 931 fields in this attribute (5). If the PA-TNC Attribute Length 932 field is less than the size of these fixed length fields, 933 implementations SHOULD respond with an Invalid Parameter PA- 934 TNC error code. 936 3.2.3. Numeric Version 938 This PA-TNC Attribute Type contains numeric version information 939 for a product on the endpoint that implements the component 940 specified in the PA Subtype field, as described in section 2.4. 941 For example, if the PA Subtype is Operating System, this 942 attribute would contain numeric version information for the 943 operating system installed on the endpoint. The version 944 information in this attribute is associated with a particular 945 product, so Posture Validators are expected to also possess the 946 corresponding Product Information attribute when interpreting 947 this attribute. 949 All Posture Collectors that implement the IETF Standard PA 950 Subtype for Operating System SHOULD support sending this 951 attribute type, at least for the Operating System PA subtype. 952 Other Posture Collectors MAY support sending this attribute 953 type. Whether a particular Posture Collector actually sends 954 this attribute type SHOULD still be governed by local privacy 955 and security policies. All Posture Validators that implement 956 the IETF Standard PA Subtype for Operating System SHOULD support 957 receiving this attribute type, at least for the Operating System 958 PA subtype. Other Posture Validators MAY support receiving this 959 attribute type. A Posture Validator that does not support 960 receiving this attribute type SHOULD simply ignore attributes 961 with this type. Posture Validators MUST NOT send this attribute 962 type. 964 For this attribute type, the PA-TNC Attribute Vendor ID field 965 MUST be set to zero (0) and the PA-TNC Attribute Type field MUST 966 be set to 3. The value in the PA-TNC Attribute Length field 967 MUST be 28 if the Correlation ID field is not present and 32 if 968 it is present. If the PA-TNC Attribute Length field is less 969 than the size of these fixed length fields, implementations 970 SHOULD respond with an Invalid Parameter PA-TNC error code. 972 This attribute type includes numeric values for the product 973 version information, enabling Posture Validators to do 974 comparative operations on the version. Some Posture Collectors 975 may not be able to determine some or all of this information for 976 a product. However, this attribute can be especially useful for 977 describing the version of the operating system, where numeric 978 version numbers are generally available. 980 The following diagram illustrates the format and contents of the 981 Attribute Value field for this attribute type. The text after 982 this diagram describes the fields shown here. 984 1 2 3 985 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 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 | Major Version Number | 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | Minor Version Number | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | Build Number | 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 | Service Pack Major | Service Pack Minor | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 Major Version Number 998 This field contains the major version number for the product, 999 if applicable. If unused or unknown, this field SHOULD be set 1000 to 0. 1002 Minor Version Number 1004 This field contains the minor version number for the product, 1005 if applicable. If unused or unknown, this field SHOULD be set 1006 to 0. 1008 Build Number 1010 This field contains the build number for the product, if 1011 applicable. This may provide more granularity than the minor 1012 version number, as many builds may occur leading up to an 1013 official release, and all these builds may share a single 1014 major and minor version number. If unused or unknown, this 1015 field SHOULD be set to 0. 1017 Service Pack Major 1019 This field contains the major version number of the service 1020 pack for the product, if applicable. If unused or unknown, 1021 this field SHOULD be set to 0. 1023 Service Pack Minor 1025 This field contains the minor version number of the service 1026 pack for the product, if applicable. If unused or unknown, 1027 this field SHOULD be set to 0. 1029 3.2.4. String Version 1031 This PA-TNC Attribute Type contains string version information 1032 for a product on the endpoint that implements the component 1033 specified in the PA Subtype field, as described in section 2.4. 1034 For example, if the PA Subtype is Firewall, this attribute would 1035 contain string version information for a host-based firewall 1036 product installed on the endpoint (if any). The version 1037 information in this attribute is associated with a particular 1038 product, so Posture Validators are expected to also possess the 1039 corresponding Product Information attribute when interpreting 1040 this attribute. 1042 All Posture Collectors that implement any of the IETF Standard 1043 PA Subtypes defined in this document MUST support sending this 1044 attribute type, at least for those PA subtypes. Other Posture 1045 Collectors MAY support sending this attribute type. Whether a 1046 particular Posture Collector actually sends this attribute type 1047 SHOULD still be governed by local privacy and security policies. 1048 All Posture Validators that implement any of the IETF Standard 1049 PA Subtypes defined in this document MUST support receiving this 1050 attribute type, at least for those PA subtypes. Other Posture 1051 Validators MAY support receiving this attribute type. Posture 1052 Validators MUST NOT send this attribute type. 1054 For this attribute type, the PA-TNC Attribute Vendor ID field 1055 MUST be set to zero (0) and the PA-TNC Attribute Type field MUST 1056 be set to 4. The value in the PA-TNC Attribute Length field 1057 will vary, depending on the length of the Component Version 1058 Number, Internal Build Number, and Configuration Version Number 1059 fields. However, the value in the PA-TNC Attribute Length field 1060 MUST be at least 15 (19 if the Correlation ID field is present) 1061 because this is the length of the fixed size fields in the PA- 1062 TNC Attribute Header and the fixed size fields in this attribute 1063 type. If the PA-TNC Attribute Length field is less than the 1064 size of these fixed length fields or does not match the length 1065 indicated by the sum of the fixed length and variable length 1066 fields, implementations SHOULD respond with an Invalid Parameter 1067 PA-TNC error code. 1069 The following diagram illustrates the format and contents of the 1070 Attribute Value field for this attribute type. The text after 1071 this diagram describes the fields shown here. 1073 1 2 3 1074 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 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 | Version Len | Product Version Number (Variable Length) | 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 | Build Num Len | Internal Build Number (Variable Length) | 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | Config. Len | Configuration Version Number (Variable Length)| 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 Version Len 1085 This field defines the number of octets in the Product 1086 Version Number field. If the product version number is 1087 unavailable or unknown, this field MUST be set to 0 and the 1088 Product Version Number field will be zero length (effectively 1089 not present). 1091 Product Version Number 1093 This field contains a UTF-8 string identifying the version of 1094 the component (e.g. "1.12.23.114"). This field MUST be sized 1095 to fit the version string and MUST NOT include extra octets 1096 for padding or NUL character termination. 1098 Various products use a wide range of different formats and 1099 semantics for version strings. Some use alphabetic 1100 characters, white space, and punctuation. Some consider 1101 version "1.21" to be later than version "1.3" and some 1102 earlier. Therefore, the syntax and semantics of this string 1103 are not defined. 1105 Build Num Len 1107 This field defines the number of octets in the Internal Build 1108 Number field. For products where the internal build number 1109 is unavailable or unknown, this field MUST be set to 0 and 1110 the Internal Build Number field will be zero length 1111 (effectively not present). 1113 Internal Build Number 1115 This field contains a UTF-8 string identifying the 1116 engineering build number of the product. This field MUST be 1117 sized to fit the build number string and MUST NOT include 1118 extra octets for padding or NUL character termination. The 1119 syntax and semantics of this string are not defined. 1121 Config. Len 1123 This field defines the number of octets in the Configuration 1124 Version Number field. If the product version number is 1125 unavailable or unknown, this field MUST be set to 0 and the 1126 Product Version Number field will be zero length (effectively 1127 not present). 1129 Configuration Version Number 1131 This field contains a UTF-8 string identifying the version of 1132 the configuration used by the component. This version SHOULD 1133 represent the overall configuration version even if several 1134 configuration policy files or settings are used. Posture 1135 Collectors MAY include multiple version numbers in this 1136 single string if a single version is not practical. This 1137 field MUST be sized to fit the version string and MUST NOT 1138 include extra octets for padding or NUL character 1139 termination. 1141 Various products use a wide range of different formats for 1142 version strings. Some use alphabetic characters, white 1143 space, and punctuation. Some consider version "1.21" to be 1144 later than version "1.3" and some earlier. In addition, some 1145 Posture Collectors may place multiple configuration version 1146 numbers in this single string. Therefore, the syntax and 1147 semantics of this string are not defined. 1149 3.2.5. Operational Status 1151 This PA-TNC Attribute Type describes the operational status of a 1152 product that can implement the component specified in the PA 1153 Subtype field, as described in section 2.4. For example, if the 1154 PA Subtype is Anti-Spyware, this attribute would contain 1155 information about the operational status of a host-based anti- 1156 spyware product that may or may not be installed on the 1157 endpoint. 1159 Posture Collectors that implement the IETF Standard PA Subtype 1160 for Operating System or VPN MAY support sending this attribute 1161 type for those PA subtypes. Posture Collectors that implement 1162 other IETF Standard PA Subtypes defined in this specification 1163 SHOULD support sending this attribute type for those PA 1164 subtypes. Other Posture Collectors MAY support sending this 1165 attribute type. Whether a particular Posture Collector actually 1166 sends this attribute type SHOULD still be governed by local 1167 privacy and security policies. Posture Validators that 1168 implement the IETF Standard PA Subtype for Operating System or 1169 VPN MAY support receiving this attribute type, at least for 1170 those PA subtypes. Posture Validators that implement other IETF 1171 Standard PA Subtypes defined in this specification SHOULD 1172 support receiving this attribute type, at least for those PA 1173 subtypes. Other Posture Validators MAY support receiving this 1174 attribute type. A Posture Validator that does not support 1175 receiving this attribute type SHOULD simply ignore attributes 1176 with this type. Posture Validators MUST NOT send this attribute 1177 type. 1179 For this attribute type, the PA-TNC Attribute Vendor ID field 1180 MUST be set to zero (0) and the PA-TNC Attribute Type field MUST 1181 be set to 5. The value in the PA-TNC Attribute Length field 1182 MUST be 36 if the Correlation ID field is not present and 40 if 1183 it is present. If the PA-TNC Attribute Length field does not 1184 have this value, implementations SHOULD respond with an Invalid 1185 Parameter PA-TNC error code. 1187 The following diagram illustrates the format and contents of the 1188 Attribute Value field for this attribute type. The text after 1189 this diagram describes the fields shown here. 1191 1 2 3 1192 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 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 | Status | Result | Reserved | 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 | Last Use | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 | Last Use (continued) | 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 | Last Use (continued) | 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 | Last Use (continued) | 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 | Last Use (continued) | 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 Status 1209 This field gives the operational status of the product. The 1210 following table lists the values currently defined for this 1211 field. As described in section 7, the IANA maintains a 1212 registry of valid values for this field so that new values 1213 can be defined. 1215 Value Description 1216 ----- ----------- 1217 0 Unknown or other 1218 1 Not installed 1219 2 Installed but not operational 1220 3 Operational 1222 If a Posture Validator receives a value for this field that 1223 it does not recognize, it SHOULD treat this value as 1224 equivalent to the value 0. 1226 Result 1228 This field contains the result of the last use of the 1229 product. The following table lists the values currently 1230 defined for this field. As described in section 7, the IANA 1231 maintains a registry of valid values for this field so that 1232 new values can be defined. 1234 Value Description 1235 ----- ----------- 1236 0 Unknown or other 1237 1 Successful use with no errors detected 1238 2 Successful use with one or more errors detected 1239 3 Unsuccessful use (e.g. aborted) 1241 Posture Collectors SHOULD set this field to 0 if the Status 1242 field contains a value of 1 (Not installed) or 2 (Installed 1243 but not operational). If a Posture Validator receives a 1244 value for this field that it does not recognize, it SHOULD 1245 treat this value as equivalent to the value 0. 1247 Reserved 1249 This field is reserved for future use. The field MUST be set 1250 to 0 on transmission and ignored upon reception. 1252 Last Use 1254 This field contains the date and time of the last use of the 1255 component. The Last Use date and time MUST be represented as 1256 an RFC 3339 [4] compliant ASCII string in Coordinated 1257 Universal Time (UTC) time with the additional restrictions 1258 that the 't' delimiter and the 'z' suffix MUST be capitalized 1259 and fractional seconds (time-secfrac) MUST NOT be included. 1260 Leap seconds are permitted and Posture Validators MUST 1261 support them. The last use string MUST NOT be NUL terminated 1262 or padded in any way. If the last use time is not known, not 1263 applicable, or cannot be represented in this format, the 1264 Posture Collector MUST set this field to the value "0000-00- 1265 00T00:00:00Z" (allowing this field to be fixed length). Not 1266 that this particular reserved value is NOT a valid RFC 3339 1267 date and time and MUST NOT be used for any other purpose in 1268 this field. 1270 This encoding produces a string that is easy to read, parse, 1271 and interpret. The format (more precisely defined in RFC 1272 3339) is YYYY-MM-DDTHH:MM:SSZ, resulting in one and only one 1273 representation for each second in UTC time from year 0000 to 1274 year 9999. For example, 9:05:00AM EST (GMT-0500) on January 1275 19, 1995 can be represented as "1995-01-19T14:05:00Z". The 1276 length of this field is always 20 octets. 1278 3.2.6. Port Filter 1280 This PA-TNC Attribute Type provides the list of port numbers and 1281 associated protocols (e.g. TCP and UDP) that are currently 1282 blocked or allowed by a host-based firewall on the endpoint. 1284 Posture Collectors that implement the IETF Standard PA Subtype 1285 for Firewall or VPN SHOULD support sending this attribute type 1286 for those PA subtypes. Posture Collectors that implement other 1287 IETF Standard PA Subtypes defined in this specification MUST NOT 1288 support sending this attribute type for those PA subtypes. 1289 Other Posture Collectors MAY support sending this attribute 1290 type, if it is appropriate to their PA subtype. Whether a 1291 particular Posture Collector actually sends this attribute type 1292 SHOULD still be governed by local privacy and security policies. 1293 Posture Validators that implement the IETF Standard PA Subtype 1294 for Firewall or VPN SHOULD support receiving this attribute 1295 type, at least for those PA subtypes. Posture Validators that 1296 implement other IETF Standard PA Subtypes defined in this 1297 specification MUST NOT support receiving this attribute type for 1298 those PA subtypes. Other Posture Validators MAY support 1299 receiving this attribute type. A Posture Validator that does 1300 not support receiving this attribute type SHOULD simply ignore 1301 attributes with this type. Posture Validators MUST NOT send 1302 this attribute type. 1304 For this attribute type, the PA-TNC Attribute Vendor ID field 1305 MUST be set to zero (0) and the PA-TNC Attribute Type field MUST 1306 be set to 6. 1308 The following diagram illustrates the format and contents of the 1309 Attribute Value field for this attribute type. The text after 1310 this diagram describes the fields shown here. 1312 Note that this diagram shows two Protocol/Port Number pairs. The 1313 actual number of Protocol/Port Number pairs included in a Port 1314 Filter attribute can vary from one to a large number (limited 1315 only by the maximum message and length supported by the 1316 underlying PT transport protocol). However, each Port Filter 1317 attribute MUST contain at least one Protocol/Port Number pair. 1318 Because the length of a Protocol/Port Number pair with the 1319 Reserved field and B flag is always 4 octets, the number of 1320 Protocol/Port Number pairs can be easily computed using the PA- 1321 TNC Attribute Length field by subtracting the number of octets 1322 in the PA-TNC Attribute Header and dividing by 4. If the PA-TNC 1323 Attribute Length field is invalid, Posture Validators SHOULD 1324 respond with an Invalid Parameter PA-TNC error code. 1326 1 2 3 1327 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 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 | Reserved |B| Protocol | Port Number | 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 | Reserved |B| Protocol | Port Number | 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 Reserved 1336 This field is reserved for future use. It MUST be set to 0 1337 on transmission and ignored upon reception. 1339 B Flag (Blocked or Allowed Port) 1341 This single bit field indicates whether the following port is 1342 blocked or allowed. This bit MUST be set to 1 if the 1343 protocol and port combination is blocked. Otherwise this 1344 field MUST be set to 0. This field was provided to allow for 1345 more abbreviated reporting of the port filtering policy (e.g. 1346 when all ports are blocked except a few, the Posture 1347 Collector can just list the few that are allowed). 1349 Posture Collectors MUST NOT provide a mixed list of block and 1350 non-blocked ports for a particular protocol. To be more 1351 precise, a Posture Collector MUST NOT include two 1352 Protocol/Port Number pairs in a single Port List attribute 1353 where the protocol number is the same but the B flag is 1354 different. Also, Posture Collectors MUST NOT list the same 1355 Protocol and Port Number combination twice in a Port List 1356 attribute. 1358 Posture Collectors MAY list all blocked ports for one 1359 protocol and all allowed ports for a different protocol in a 1360 single Port List attribute, using the B flag to indicate 1361 whether each entry is blocked. For example, a Posture 1362 Collector might list all the blocked TCP ports but only list 1363 the allowed UDP ports. However it MUST NOT list some blocked 1364 TCP ports and some other allowed TCP ports. 1366 Protocol 1368 This field contains the protocol number being blocked or 1369 allowed. The values used in this field are the same ones used 1370 in the IPv4 Protocol and IPv6 Next Header fields. The IANA 1371 already maintains a registry of these values. 1373 Port Number 1375 This field contains the port number being blocked or allowed. 1376 The values used in this field are specific to the protocol 1377 identified by the Protocol field. The IANA maintains 1378 registries for TCP and UDP port numbers. 1380 3.2.7. Installed Packages 1382 This PA-TNC Attribute Type contains a list of the installed 1383 packages that comprise a product on the endpoint that implements 1384 the component specified in the PA Subtype field, as described in 1385 section 2.4. This allows a Posture Validator to check which 1386 packages are installed for a particular product and which 1387 versions of those packages are installed. 1389 Posture Collectors that implement any of the IETF Standard PA 1390 Subtypes defined in this document SHOULD support sending this 1391 attribute type for those PA subtypes. Other Posture Collectors 1392 MAY support sending this attribute type, if it is appropriate to 1393 their PA subtype. Whether a particular Posture Collector 1394 actually sends this attribute type SHOULD still be governed by 1395 local privacy and security policies. Posture Validators that 1396 implement any of the IETF Standard PA Subtypes defined in this 1397 document SHOULD support receiving this attribute type, at least 1398 for those PA subtypes. Other Posture Validators MAY support 1399 receiving this attribute type. A Posture Validator that does 1400 not support receiving this attribute type SHOULD simply ignore 1401 attributes with this type. Posture Validators MUST NOT send 1402 this attribute type. 1404 This attribute type can be quite long, especially for the 1405 Operating System PA subtype. This can cause problems, especially 1406 with 802.1X and other limited transport protocols. Therefore, 1407 Posture Collectors SHOULD NOT send this attribute unless 1408 specifically requested to do so using the Attribute Request 1409 attribute or otherwise configured to do so. Also, Posture 1410 Validators SHOULD NOT request this attribute unless the 1411 transport protocol in use can support the large amount of data 1412 that may be sent in response. 1414 For this attribute type, the PA-TNC Attribute Vendor ID field 1415 MUST be set to zero (0) and the PA-TNC Attribute Type field MUST 1416 be set to 7. The value in the PA-TNC Attribute Length field 1417 will vary, depending on the number of packages and the length of 1418 the Package Name and Package Version Number fields for those 1419 packages. However, the value in the PA-TNC Attribute Length 1420 field MUST be at least 16 (20 if the Correlation ID field is 1421 present) because this is the length of the fixed size fields in 1422 the PA-TNC Attribute Header and the fixed size fields in this 1423 attribute type. If the PA-TNC Attribute Length field is less 1424 than the size of these fixed length fields or does not match the 1425 length indicated by the sum of the fixed length and variable 1426 length fields, implementations SHOULD respond with an Invalid 1427 Parameter PA-TNC error code. 1429 The following diagram illustrates the format and contents of the 1430 Attribute Value field for this attribute type. The text after 1431 this diagram describes the fields shown here. 1433 Note that this diagram shows an attribute containing information 1434 on one package. The actual number of package descriptions 1435 included in an Installed Packages attribute is indicated by the 1436 Package Count field. This value may vary from zero to a large 1437 number (up to 65535, if the underlying PT transport protocol can 1438 support that many). If this number is not sufficient, 1439 specialized patch management software should be employed which 1440 can simply report compliance with a pre-established patch 1441 policy. 1443 1 2 3 1444 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 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 | Reserved | Package Count | 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 | Pkg Name Len | Package Name (Variable Length) | 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 | Version Len | Package Version Number (Variable Length) | 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 Reserved 1455 This field is reserved for future use. The field MUST be set 1456 to 0 on transmission and ignored upon reception. 1458 Package Count 1460 This field is an unsigned 16-bit integer that indicates the 1461 number of packages listed in this attribute. For each 1462 package so indicated, a Pkg Name Len, Package Name, Version 1463 Len, and Package Version Number field is included in the 1464 attribute. 1466 Pkg Name Len 1468 This field is an unsigned 8-bit integer that indicates the 1469 length of the Package Name field in octets. This field may be 1470 zero if a Package Name is not available. 1472 Package Name 1474 This field contains the name of the package associated with 1475 the product. This field is a UTF-8 encoded character string 1476 whose octet length is given by the Pkg Name Len field. This 1477 field MUST NOT include extra octets for padding or NUL 1478 character termination. The syntax and semantics of this name 1479 are not specified in this document, since they may vary 1480 across products and/or operating systems. Posture Collectors 1481 MAY list two packages with the same name in a single 1482 Installed Packages attribute. The meaning of doing so is not 1483 defined here. 1485 Version Len 1487 This field is an unsigned 8-bit integer that indicates the 1488 length of the Package Version Number field in octets. This 1489 field may be zero if a Package Version Number is not 1490 available. 1492 Package Version Number 1494 This field contains the version string for the package named 1495 in the previous Package Name field. This field is a UTF-8 1496 encoded character string whose octet length is given by the 1497 Version Len field. This field MUST NOT include extra octets 1498 for padding or NUL character termination. The syntax and 1499 semantics of this version string are not specified in this 1500 document, since they may vary across products and/or 1501 operating systems. Posture Collectors MAY list two packages 1502 with the same Package Version Number (and even the same 1503 Package Name and Package Version Number) in a single 1504 Installed Packages attribute. The meaning of doing so is not 1505 defined here. 1507 3.2.8. PA-TNC Error 1509 This PA-TNC Attribute Type contains an error code and 1510 supplemental information regarding an error pertaining to PA- 1511 TNC. 1513 All Posture Collectors and Posture Validators that implement any 1514 of the IETF Standard PA Subtypes defined in this specification 1515 MUST support sending and receiving this attribute type, at least 1516 for those PA subtypes. 1518 For this attribute type, the PA-TNC Attribute Vendor ID field 1519 MUST be set to zero (0) and the PA-TNC Attribute Type field MUST 1520 be set to 8. The value in the PA-TNC Attribute Length field 1521 will vary, depending on the length of the Error Information 1522 field. However, the value in the PA-TNC Attribute Length field 1523 MUST be at least 20 (24 if the Correlation ID field is present) 1524 because this is the length of the fixed size fields in the PA- 1525 TNC Attribute Header and the fixed size fields in this attribute 1526 type. 1528 A PA-TNC error code SHOULD be sent with the same PA Message 1529 Vendor ID and PA Subtype used by the PA-TNC message that caused 1530 the error so that the error code is sent to the party who sent 1531 the offending PA-TNC message. Other measures (such as setting 1532 PB-TNC's EXCL flag and Posture Collector Identifier or Posture 1533 Validator Identifier fields) SHOULD also be taken to attempt to 1534 ensure that only the party who sent the offending message 1535 receives the error. 1537 When a PA-TNC error code is received, the recipient MUST NOT 1538 respond with a PA-TNC error code because this could result in an 1539 infinite loop of errors. Instead, the recipient MAY log the 1540 error, modify its behavior to attempt to avoid the error 1541 (attempting to avoid loops or long strings of errors), ignore 1542 the error, terminate the assessment, or take other action as 1543 appropriate (as long as it is consistent with the requirements 1544 of this specification). 1546 Posture Verifiers MUST NOT include this attribute type in an 1547 Attribute Request attribute. It does not make sense for a 1548 Posture Verifier to request that a Posture Collector send a PA- 1549 TNC Error attribute. 1551 The following diagram illustrates the format and contents of the 1552 Attribute Value field for this attribute type. The text after 1553 this diagram describes the fields shown here. 1555 1 2 3 1556 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 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1558 | Reserved | PA-TNC Error Code Vendor ID | 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1560 | PA-TNC Error Code | 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 | Error Information (Variable Length) | 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1565 Reserved 1566 This field is reserved for future use. This field MUST be 1567 set to 0 on transmission and ignored upon reception. 1569 PA-TNC Error Code Vendor ID 1571 This field contains the SMI Private Enterprise Number for the 1572 organization that defined the PA-TNC Error Code that is being 1573 used in the attribute. For IETF Standard PA-TNC Error Code 1574 values this field MUST be set to zero (0). 1576 PA-TNC Error Code 1578 This field contains the PA-TNC Error Code being reported in 1579 this attribute. Note that a particular PA-TNC Error Code 1580 value will have completely different meanings depending on 1581 the PA-TNC Error Code Vendor ID. Each PA-TNC Error Code 1582 Vendor ID defines a different space of PA-TNC Error Code 1583 values. 1585 When the PA-TNC Error Code Vendor ID is set to zero (0), the 1586 PA-TNC Error Code is an IETF Standard PA-TNC Error Code. The 1587 IANA maintains a registry for these values. The following 1588 table lists the IETF Standard PA-TNC Error Codes defined in 1589 this specification: 1591 Value Description 1592 ----- ----------- 1593 0 Reserved 1594 1 Invalid Parameter 1595 2 Version Not Supported 1596 3 Attribute Type Not Supported 1598 The next few subsections of this document provide detailed 1599 definitions of these error codes. 1601 Error Information 1603 This field provides additional context for the error. The 1604 contents of this field vary based on the PA-TNC Error Code 1605 Vendor ID and PA-TNC Error Code. Therefore, whenever a PA-TNC 1606 Error Code is defined, the format of this field for that 1607 error code must also be defined. The definitions of IETF 1608 Standard PA-TNC Error Codes on the next few pages provide 1609 good examples of such definitions. 1611 The length of this field can be determined by the recipient 1612 using the PA-TNC Attribute Length field by subtracting the 1613 length of the fixed-length fields in the PA-TNC Attribute 1614 Header and the fixed-length fields in this attribute. 1616 3.2.8.1. Definition of Invalid Parameter Error Code 1618 The Invalid Parameter error code is an IETF Standard PA-TNC 1619 Error Code (value 1) that indicates that the sender of this 1620 error code has detected an invalid value in a PA-TNC message 1621 sent by the recipient of this error code in the current 1622 assessment. 1624 For this error code, the Error Information field contains the 1625 first 8 octets of the PA-TNC message that contained the invalid 1626 parameter and an offset indicating the position within that 1627 message of the invalid parameter. 1629 The following diagram illustrates the format and contents of the 1630 Error Information field for this error code. The text after 1631 this diagram describes the fields shown here. 1633 1 2 3 1634 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 1635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1636 | Version | Copy of Reserved | 1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 | Message Identifier | 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 | Offset | 1641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1643 Version 1645 This field MUST contain an exact copy of the Version field in 1646 the PA-TNC Message Header of the PA-TNC message that caused 1647 this error. 1649 Copy of Reserved 1650 This field MUST contain an exact copy of the Reserved field 1651 in the PA-TNC Message Header of the PA-TNC message that 1652 caused this error. 1654 Message Identifier 1656 This field MUST contain an exact copy of the Message 1657 Identifier field in the PA-TNC Message Header of the PA-TNC 1658 message that caused this error. 1660 Offset 1662 This field MUST contain an octet offset from the start of the 1663 PA-TNC Message Header of the PA-TNC message that caused this 1664 error to the start of the value that caused this error. For 1665 instance, if the first PA-TNC attribute in the message had an 1666 invalid PA-TNC Attribute Length (e.g. 0), this value would be 1667 16. 1669 3.2.8.2. Definition of Version Not Supported Error Code 1671 The Version Not Supported error code is an IETF Standard PA-TNC 1672 Error Code (value 2) that indicates that the sender of this 1673 error code does not support the PA-TNC version number included 1674 in the PA-TNC Message Header of a PA-TNC message sent by the 1675 recipient of this error code in the current assessment. 1677 For this error code, the Error Information field contains the 1678 first 8 octets of the PA-TNC message that contained the 1679 unsupported version as well as Max Version and Min Version 1680 fields that indicate which PA-TNC version numbers are supported 1681 by the sender of the error code. 1683 The sender MUST support all PA-TNC versions between the Min 1684 Version and the Max Version, inclusive (i.e. including the Min 1685 Version and the Max Version). When possible, recipients of this 1686 error code SHOULD send future messages to the Posture Collector 1687 or Posture Validator that originated this error message with a 1688 PA-TNC version number within the stated range. 1690 Any party that is sending the Version Not Supported error code 1691 SHOULD include that error code as the only PA-TNC attribute in a 1692 PA-TNC message with version number 1. All parties that send PA- 1693 TNC messages SHOULD be able to properly process a message that 1694 meets this description, even if they cannot process any other 1695 aspect of PA-TNC version 1. This ensures that a PA-TNC version 1696 exchange can proceed properly, no matter what versions of PA-TNC 1697 the parties implement. 1699 The following diagram illustrates the format and contents of the 1700 Error Information field for this error code. The text after 1701 this diagram describes the fields shown here. 1703 1 2 3 1704 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 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 | Version | Copy of Reserved | 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 | Message Identifier | 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 | Max Version | Min Version | Reserved | 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 Version 1715 This field MUST contain an exact copy of the Version field in 1716 the PA-TNC Message Header of the PA-TNC message that caused 1717 this error. 1719 Copy of Reserved 1721 This field MUST contain an exact copy of the Reserved field 1722 in the PA-TNC Message Header of the PA-TNC message that 1723 caused this error. 1725 Message Identifier 1727 This field MUST contain an exact copy of the Message 1728 Identifier field in the PA-TNC Message Header of the PA-TNC 1729 message that caused this error. 1731 Max Version 1733 This field MUST contain the maximum PA-TNC version supported 1734 by the sender of this error code. 1736 Min Version 1738 This field MUST contain the minimum PA-TNC version supported 1739 by the sender of this error code. 1741 Reserved 1743 Reserved for future use. This field MUST be set to 0 on 1744 transmission and ignored upon reception. 1746 3.2.8.3. Definition of Attribute Type Not Supported Error Code 1748 The Attribute Type Not Supported error code is an IETF Standard 1749 PA-TNC Error Code (value 3) that indicates that the sender of 1750 this error code does not support the PA-TNC Attribute Type 1751 included in the Error Information field. This PA-TNC Attribute 1752 Type was included in a PA-TNC message sent by the recipient of 1753 this error code in the current assessment. 1755 For this error code, the Error Information field contains the 1756 first 8 octets of the PA-TNC message that contained the 1757 unsupported attribute type as well as a copy of the attribute 1758 type that caused the problem. 1760 The following diagram illustrates the format and contents of the 1761 Error Information field for this error code. The text after 1762 this diagram describes the fields shown here. 1764 1 2 3 1765 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 1766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1767 | Version | Reserved | 1768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1769 | Message Identifier | 1770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1771 | Flags | PA-TNC Attribute Vendor ID | 1772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1773 | PA-TNC Attribute Type | 1774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1776 Version 1778 This field MUST contain an exact copy of the Version field in 1779 the PA-TNC Message Header of the PA-TNC message that caused 1780 this error. 1782 Copy of Reserved 1784 This field MUST contain an exact copy of the Reserved field 1785 in the PA-TNC Message Header of the PA-TNC message that 1786 caused this error. 1788 Message Identifier 1790 This field MUST contain an exact copy of the Message 1791 Identifier field in the PA-TNC Message Header of the PA-TNC 1792 message that caused this error. 1794 Flags 1796 This field MUST contain an exact copy of the Flags field in 1797 the PA-TNC Attribute Header of the PA-TNC attribute that 1798 caused this error. 1800 PA-TNC Attribute Vendor ID 1801 This field MUST contain an exact copy of the PA-TNC Attribute 1802 Vendor ID field in the PA-TNC Attribute Header of the PA-TNC 1803 attribute that caused this error. 1805 PA-TNC Attribute Type 1807 This field MUST contain an exact copy of the PA-TNC Attribute 1808 Type field in the PA-TNC Attribute Header of the PA-TNC 1809 attribute that caused this error. 1811 3.3. Vendor-Defined Attributes 1813 This section discusses the use of vendor-defined attributes 1814 within PA-TNC. The PA-TNC protocol was designed to allow for 1815 vendor-defined attributes to be used as a replacement where a 1816 standard attribute could be used. In some cases even the 1817 standard attributes allow for vendor-defined information to be 1818 included. It is envisioned that over time as particular vendor- 1819 defined attributes become popular, an equivalent standard 1820 attribute could be added allowing for broader interoperability. 1822 This specification does not define vendor-defined attributes, 1823 but rather highlights how such attributes can be used with PA- 1824 TNC without the potential for name space collisions or 1825 misinterpretations. In order to avoid collisions, PA-TNC uses 1826 the well-established SMI Private Enterprise Numbers as Vendor 1827 IDs to define separate name spaces for important fields within a 1828 PA-TNC message. For example, to ensure the uniqueness of 1829 attribute types while providing for vendor extensions, vendor- 1830 defined attribute types include the vendor's unique Vendor ID, 1831 to indicate the intended name space for the attribute type, 1832 followed by the attribute type. IETF Standard PA-TNC Attribute 1833 Types use a Vendor ID of zero (0). 1835 SMI Private Enterprise Numbers are used to provide a separate 1836 identifier space for each vendor. The IANA provides a registry 1837 for SMI Private Enterprise Numbers. Any organization (including 1838 non-profit organizations, governmental bodies, etc.) can obtain 1839 one of these numbers at no charge and thousands of organizations 1840 have done so. Within this document, SMI Private Enterprise 1841 Numbers are known as "vendor IDs". 1843 4. Evaluation Against NEA Requirements 1845 This section evaluates the PA-TNC protocol against the 1846 requirements defined in the NEA Requirements document. Each 1847 subsection considers a separate requirement from the NEA 1848 Requirements document. Only common requirements (C-1 through C- 1849 10) and PA requirements (PA-1 through PA-6) are considered, 1850 since these are the only ones that apply to PA. 1852 4.1. Evaluation Against Requirement C-1 1854 Requirement C-1 says: 1856 C-1 NEA protocols MUST support multiple round trips between 1857 the NEA Client and NEA Server in a single assessment. 1859 PA-TNC meets this requirement. It allows an unlimited number of 1860 round trips between the NEA Client and NEA Server. 1862 4.2. Evaluation Against Requirement C-2 1864 Requirement C-2 says: 1866 C-2 NEA protocols SHOULD provide a way for both the NEA Client 1867 and the NEA Server to initiate a posture assessment or 1868 reassessment as needed. 1870 PA-TNC meets this requirement. PA-TNC is designed to work 1871 whether the NEA Client or the NEA Server initiates a posture 1872 assessment or reassessment. 1874 4.3. Evaluation Against Requirement C-3 1876 Requirement C-3 says: 1878 C-3 NEA protocols including security capabilities MUST be 1879 capable of protecting against active and passive attacks 1880 by intermediaries and endpoints including prevention from 1881 replay based attacks. 1883 Security for PA-TNC can be provided through PT security or 1884 through the use of PA-TNC security, which is defined in a 1885 separate specification: PA-TNC Security [8]. Therefore, this 1886 base specification for PA-TNC does not include any security 1887 capabilities. Since this requirement only applies to NEA 1888 protocols that include security capabilities, this base 1889 specification for PA-TNC meets this requirement. 1891 4.4. Evaluation Against Requirement C-4 1893 Requirement C-4 says: 1895 C-4 The PA and PB protocols MUST be capable of operating over 1896 any PT protocol. For example, the PB protocol must 1897 provide a transport independent interface allowing the PA 1898 protocol to operate without change across a variety of 1899 network protocol environments (e.g. EAP/802.1X, PANA, TLS 1900 and IKE/IPsec). 1902 PA-TNC meets this requirement. PA-TNC can operate over any PT 1903 protocol that meets the requirements for PT stated in the NEA 1904 Requirements document. PA-TNC does not have any dependencies on 1905 specific details of the underlying PT protocol. 1907 4.5. Evaluation Against Requirement C-5 1909 Requirement C-5 says: 1911 C-5 The selection process for NEA protocols MUST evaluate and 1912 prefer the reuse of existing open standards that meet the 1913 requirements before defining new ones. The goal of NEA is 1914 not to create additional alternative protocols where 1915 acceptable solutions already exist. 1917 Based on this requirement, PA-TNC should receive a strong 1918 preference. PA-TNC is equivalent with IF-M 1.0, an open TCG 1919 specification. Other specifications from TCG and other groups 1920 are also under development based on the IF-M 1.0 specification. 1921 Selecting PA-TNC as the basis for the PA protocol will ensure 1922 compatibility with IF-M 1.0, with these other specifications, 1923 and with their implementations. 1925 4.6. Evaluation Against Requirement C-6 1927 Requirement C-6 says: 1929 C-6 NEA protocols MUST be highly scalable; the protocols MUST 1930 support many Posture Collectors on a large number of NEA 1931 Clients to be assessed by numerous Posture Validators 1932 residing on multiple NEA Servers. 1934 PA-TNC meets this requirement. PA-TNC supports an unlimited 1935 number of Posture Collectors, Posture Validators, NEA Clients, 1936 and NEA Servers. It also is quite scalable in many other 1937 aspects as well. A PA-TNC message can contain up to 2^32-1 1938 octets and about 2^28 PA-TNC attributes. Each organization with 1939 an SMI Private Enterprise Number is entitled to define up to 1940 2^32 vendor-specific PA-TNC Attribute Types, 2^16 vendor- 1941 specific PA-TNC Product IDs, and 2^32 vendor-specific PA-TNC 1942 Error Codes. Each attribute can contain almost 2^32 octets. It 1943 is generally not advisable or necessary to send this much data 1944 in a NEA assessment, but still PA-TNC is highly scalable and 1945 meets requirement C-6 easily. 1947 4.7. Evaluation Against Requirement C-7 1949 Requirement C-7 says: 1951 C-7 The protocols MUST support efficient transport of a large 1952 number of attribute messages between the NEA Client and 1953 the NEA Server. 1955 PA-TNC meets this requirement. Each PA-TNC message can contain 1956 about 2^28 PA-TNC attributes. PA-TNC supports up to 2^32 round 1957 trips in a session so the maximum number of attribute messages 1958 that can be sent in a single session is actually about 2^50. 1959 However, it is generally inadvisable and unnecessary to send a 1960 large number of messages in a NEA assessment. As for 1961 efficiency, PA-TNC adds only 12 octets of overhead per attribute 1962 and 8 octets per message (which is negligible on a per-attribute 1963 basis). 1965 4.8. Evaluation Against Requirement C-8 1967 Requirement C-8 says: 1969 C-8 NEA protocols MUST operate efficiently over low bandwidth 1970 or high latency links. 1972 PA-TNC meets this requirement. A typical PA-TNC exchange will 1973 involve one or two round trips with less than 500 octets of PA- 1974 TNC messages. Of course, use of PA-TNC security or vendor- 1975 specific PA-TNC attribute types could expand the assessment. 1976 However, PA-TNC itself imposes an overhead of only 8 octets per 1977 PA-TNC message and 12 octets per attribute. 1979 4.9. Evaluation Against Requirement C-9 1981 Requirement C-9 says: 1983 C-9 For any strings intended for display to a user, the 1984 protocols MUST support adapting these strings to the 1985 user's language preferences. 1987 PA-TNC meets this requirement. The fields defined here do not 1988 include any strings intended for display to a user. They are 1989 intended for logging and programmatic comparisons. 1991 If any vendor-specific PA-TNC attribute types or future IETF 1992 Standard PA-TNC Attribute Types include strings that are 1993 intended for display to a user, they can be adapted to the 1994 user's language preferences using the PB-TNC protocol's ability 1995 to exchange information about those preferences in a standard 1996 manner. The Posture Broker Server will need to expose the 1997 user's preferences to the Posture Validators through whatever 1998 API or protocol is used to connect those components. However, 1999 that is all out of scope for this specification. 2001 4.10. Evaluation Against Requirement C-10 2003 Requirement C-10 says: 2005 C-10 NEA protocols MUST support encoding of strings in UTF-8 2006 format. 2008 PA-TNC meets this requirement. All strings in the PA-TNC 2009 protocol are encoded in UTF-8 format. This allows the protocol 2010 to support a wide range of languages efficiently. 2012 4.11. Evaluation Against Requirement PA-1 2014 Requirement PA-1 says: 2016 PA-1 The PA protocol MUST support communication of an 2017 extensible set of NEA standards defined attributes. These 2018 attributes will be uniquely identifiable from non-standard 2019 attributes. 2021 PA-TNC meets this requirement. Each attribute is identified 2022 with a PA-TNC Attribute Vendor ID and a PA-TNC Attribute Type. 2023 IETF Standard PA-TNC Attribute Types use a vendor ID of zero 2024 (0), in contrast with vendor-specific PA-TNC Attribute Types, 2025 which will use the vendor's SMI Private Enterprise Number as the 2026 vendor ID. The IANA will maintain a registry of IETF Standard 2027 PA-TNC Attribute Types with new values added by IETF Consensus, 2028 as described in the IANA Considerations section of this 2029 specification. Thus, the set of standard attribute types is 2030 extensible, but all standard attribute types are uniquely 2031 identifiable. 2033 4.12. Evaluation Against Requirement PA-2 2035 Requirement PA-2 says: 2037 PA-2 The PA protocol MUST support communication of an 2038 extensible set of vendor-specific attributes. These 2039 attributes will be segmented into uniquely identifiable 2040 vendor specific name spaces. 2042 PA-TNC meets this requirement. Each attribute is identified 2043 with a PA-TNC Attribute Vendor ID and a PA-TNC Attribute Type. 2044 Vendor-defined PA-TNC Attribute Types use the vendor's SMI 2045 Private Enterprise Number as the PA-TNC Attribute Vendor ID. 2046 Each vendor can define up to 2^32 PA-TNC Attribute Types, using 2047 its own internal processes to manage its set of attribute types. 2048 The IANA is not involved, other than the initial assignment of 2049 the vendor's SMI Private Enterprise Number. Thus, the set of 2050 vendor-specific attributes is segmented into uniquely 2051 identifiable vendor-specific name spaces. 2053 4.13. Evaluation Against Requirement PA-3 2055 Requirement PA-3 says: 2057 PA-3 The PA protocol MUST enable a Posture Validator to make 2058 one or more requests for attributes from a Posture 2059 Collector within a single assessment. This enables the 2060 Posture Validator to reassess the posture of a particular 2061 endpoint feature or to request additional posture 2062 including from other parts of the endpoint. 2064 PA-TNC meets this requirement. The Attribute Request attribute 2065 type is an IETF Standard PA-TNC Attribute Type that permits a 2066 Posture Validator to send to one or more Posture Collectors a 2067 request for one or more attributes. This attribute may be sent 2068 at any point in the posture assessment process and may in fact 2069 be sent more than once if the Posture Validator needs to first 2070 determine the type of operating system and then request certain 2071 attributes specific to that operating system, for example. 2073 4.14. Evaluation Against Requirement PA-4 2075 Requirement PA-4 says: 2077 PA-4 The PA protocol MUST be capable of returning attributes 2078 from a Posture Validator to a Posture Collector. For 2079 example, this might enable the Posture Collector to learn 2080 the specific reason for a failed assessment and to aid in 2081 remediation and notification of the system owner. 2083 PA-TNC meets this requirement. A Posture Validator can easily 2084 send attributes to one or more Posture Collectors. 2086 4.15. Evaluation Against Requirement PA-5 2088 Requirement PA-5 says: 2090 PA-5 The PA protocol SHOULD provide authentication, integrity, 2091 and confidentiality of attributes communicated between a 2092 Posture Collector and Posture Validator. This enables 2093 end-to-end security across a NEA deployment that might 2094 involve traversal of several systems or trust boundaries. 2096 PA-TNC meets this requirement when a PA-TNC Security mechanism 2097 is used, such as PA-TNC Security with CMS. The specifications 2098 for those mechanisms should be consulted for a complete analysis 2099 of their security properties. 2101 PA-TNC Security is an optional addition to PA-TNC because 2102 different products and deployments may require different 2103 security mechanisms. For example, one product might integrate 2104 Posture Validators, the Posture Broker Server, and the Posture 2105 Transport Server into a single entity. In that case, PA-TNC 2106 security may not be needed. PT security may be enough. Another 2107 deployment may employ remote Posture Validators in the same 2108 trust domain as the Posture Broker Server. In that case, a TLS 2109 session between the Posture Broker Server and the Posture 2110 Validators may suffice. A third deployment may include a Posture 2111 Broker Server that is not trusted to see PA-TNC messages, at 2112 least for some Posture Validators. In that case, PA-TNC security 2113 may be desirable. Even there, some deployments may wish to use 2114 PKI (Public Key Infrastructure) for security, while others may 2115 wish to use Kerberos or another mechanism. 2117 4.16. Evaluation Against Requirement PA-6 2119 Requirement PA-6 says: 2121 PA-6 The PA protocol MUST be capable of carrying attributes 2122 that contain non-binary and binary data including 2123 encrypted content. 2125 PA-TNC meets this requirement. PA-TNC attributes can contain 2126 non-binary and binary data including encrypted content. For 2127 examples, see the attribute type definitions contained in this 2128 specification and in the PA-TNC Security with CMS specification. 2130 5. Security Considerations 2132 This section discusses the major types of potential security 2133 threats relevant to the PA-TNC message protocol and summarizes 2134 the expected security protections that should be offered by PA- 2135 TNC security protocols. PA-TNC security protocols are described 2136 in separate specifications which layer upon the base PA-TNC 2137 protocol described in this specification. It is envisioned that 2138 additional attribute types will be defined to facilitate the 2139 exchange of security capabilities, keys, and security protected 2140 attributes. Ultimately, the NEA deployer decides which security 2141 protection is most appropriate for a particular deployment 2142 environment. The security protections discussed in this section 2143 highlight the need for PA-TNC security protocol implementations 2144 to be capable of offering the feature. 2146 5.1. Trust Relationships 2148 In order to understand where security countermeasures are 2149 necessary, this section starts with a discussion of where the 2150 TNC architecture envisions some trust relationships between the 2151 processing elements of the PA-TNC protocol. Some deployments 2152 may wish to reduce the amount of assumed trust by using a PA-TNC 2153 security protocol to protect the PA-TNC messages. The following 2154 sub-sections discuss the trust properties associated with each 2155 portion of the NEA reference model directly involved with the 2156 processing of the PA-TNC protocol. 2158 5.1.1. Posture Collector 2160 The Posture Collectors are trusted by Posture Validators to: 2162 o Collect valid information about the component type associated 2163 with the Posture Collector 2165 o Report upon collected information consistent with local 2166 security and privacy policies 2168 o Accurately report information associated with the type of 2169 component for the PA-TNC message 2171 o Not act maliciously to the Posture Broker Server and Posture 2172 Validators, including attacks such as Denial Of Service 2174 5.1.2. Posture Validator 2176 The Posture Validators are trusted by Posture Collectors to: 2178 o Only request information necessary to assess the security 2179 state of the endpoint 2181 o Make assessment decisions based on deployer defined policies 2183 o Discard collected information consistent with data retention 2184 and privacy policies 2186 o Not act maliciously to the Posture Broker Server and Posture 2187 Collectors, including attacks such as Denial Of Service 2189 5.1.3. Posture Broker Client, Posture Broker Server, and PB-TNC 2191 The Posture Broker Client and Posture Broker Server are trusted 2192 by the Posture Collector and Posture Validator to: 2194 o Provide a reliable transport for PA-TNC messages 2196 o Deliver messages for a particular PA Subtype only to those 2197 Posture Collectors and Posture Validators that have 2198 registered for them 2200 o Not disclose any provided attributes to unauthorized parties 2202 o Not act maliciously to drop messages, duplicate messages, or 2203 flood the Posture Collectors and Posture Validators with 2204 unnecessary messages 2206 o Not observe, fabricate, or alter the contents of a PA-TNC 2207 message (this trust can be minimized with a PA-TNC security 2208 protocol) 2210 o Properly place Posture Collector and Posture Validator 2211 identifiers into the PB-TNC protocol, deliver those 2212 identifiers to Posture Collectors and Posture Validators as 2213 needed, and manage exclusive delivery to a particular Posture 2214 Collector or Posture Validator 2216 o Properly expose authentication information from PT security 2217 so that Posture Collectors and Posture Validators can use 2218 this to make policy decisions 2220 5.2. Security Threats 2222 Beyond the trusted relationships assumed in section 5.1, the PA- 2223 TNC protocol faces a number of potential security attacks that 2224 could require targeted security countermeasures. PA-TNC 2225 security protocol specifications MUST state if and how the 2226 security protocol will safeguard against these types of attack. 2228 Generally the PA-TNC protocol, without the presence of security 2229 countermeasures, relies upon the underlying PT protocol to 2230 protect the messages from attack when traveling over the 2231 network. Once the message resides on the Posture Broker Client 2232 or Posture Broker Server, it is trusted to be properly and 2233 safely delivered to the appropriate Posture Collectors and 2234 Posture Validators. However, in some deployments the PA-TNC 2235 messages need to travel over network hops that are not protected 2236 by PT or require more assurance that only the appropriate 2237 Posture Collector or Posture Validator has received the message. 2238 In these cases, end to end PA-TNC message protection might be 2239 required. The following sub-sections focus on the potential 2240 threats where end to end protection might be desired and thus 2241 when the use of the PA-TNC security protocol becomes beneficial. 2243 5.2.1. Attribute Theft 2245 When PA-TNC messages are sent over unprotected network links or 2246 spanning local software stacks that are not trusted, the 2247 contents of the PA-TNC messages may be subject to information 2248 theft by an intermediary party. This theft could result in 2249 information being recorded for future use or analysis by the 2250 adversary. Attributes observed by eavesdroppers could contain 2251 information that exposes potential weaknesses in the security of 2252 the endpoint, or system fingerprinting information easing the 2253 ability of the attacker to employ attacks more likely to be 2254 successful against the endpoint. The eavesdropper might also 2255 learn information about the endpoint or network policies that 2256 either singularly or collectively is considered sensitive 2257 information (e.g. certain endpoints are lacking patches, or 2258 particular sub-networks have more lenient policies). PA-TNC 2259 attributes are not intended to carry privacy-sensitive 2260 information, but should some exist in a message, the adversary 2261 could come into possession of the information which could be 2262 used for other financial gain. 2264 5.2.2. Message Fabrication 2266 Attackers on the network or present within the NEA system could 2267 introduce fabricated PA-TNC messages intending to trick or 2268 create a denial of service against aspects of an assessment. 2269 This could occur if an active attacker could launch a man-in- 2270 the-middle (MiTM) attack by proxying the PA-TNC messages and was 2271 able to replace undesired messages with ones easing future 2272 attack upon the endpoint. Consider a scenario where PT security 2273 protection is not used, and the Posture Broker Server proxies 2274 all assessment traffic to a remote Posture Broker Server. The 2275 proxy could eavesdrop and replace assessment results attributes, 2276 tricking the endpoint into thinking it has passed an assessment, 2277 when in fact it has not and requires remediation. Because the 2278 Posture Collector has no way to verify that attributes were 2279 actually created by an authentic Posture Validator, it is unable 2280 to detect the falsified attribute or message. 2282 5.2.3. Attribute Modification 2284 This attack could allow an active attacker capable of 2285 intercepting a message to modify a PA-TNC message attribute to a 2286 desired value to ease the compromise of an endpoint. Without 2287 the ability for message recipients to detect whether a received 2288 message contains the same content as what was originally sent, 2289 active attackers can stealthily modify the attribute exchange. 2290 For example, an attacker might wish to change the contents of 2291 the firewall component's version string attribute to disguise 2292 the fact that the firewall is running an old, vulnerable 2293 version. The attacker would change the version string sent by 2294 the firewall Posture Collector to the current version number, so 2295 the Posture Validator's assessment passes while leaving the 2296 endpoint vulnerable to attack. Similarly, an attacker could 2297 achieve widespread denial of service by altering large numbers 2298 of assessments' version string attributes to an old value so 2299 they repeatedly fail assessments even after a successful 2300 remediation. Upon receiving the lower value, the Posture 2301 Validator would continue to believe that the endpoint is running 2302 old, potentially vulnerable versions of the firewall that does 2303 not meet network compliance policy, so therefore the endpoint 2304 would not be allowed to join the network. 2306 5.2.4. Attribute Replay 2308 Another potential attack against an unprotected PA-TNC message 2309 attribute exchange is to exploit the lack of a strong binding 2310 between the attributes sent during an assessment to the specific 2311 endpoint. Without a strong binding of the endpoint to the 2312 measurement information, an attacker could record the attributes 2313 sent during an assessment of a compliant endpoint and later 2314 replay those attributes so that a non-compliant endpoint can now 2315 gain access to the network or protected resource. This attack 2316 could be employed by a network MiTM that is able to eavesdrop 2317 and proxy message exchanges, or by using local rogue agents on 2318 the endpoints. Assessments lacking some form of freshness 2319 exchange could be subject to replay of prior assessment data, 2320 even if it no longer reflects the current state of the endpoint. 2322 5.2.5. Attribute Insertion 2324 Similar to the attribute modification attacks, an adversary 2325 wishing to include one or more attributes or PA-TNC messages 2326 inside a valid assessment may be able to insert the attributes 2327 or messages without detection is possible by the recipient. 2328 Even if authentication of the parties is present during a PA-TNC 2329 exchange, if no per-message and per-session integrity protection 2330 is present, an attacker can add information to the assessment, 2331 possibly causing incorrect assessment results. For example, an 2332 attacker could add attributes to the front of a PA-TNC message 2333 to cause an assessment to succeed even for a non-compliant 2334 endpoint, particularly if it knew that the recipient ignored 2335 repeated attributes within a message. Similarly, if a Posture 2336 Collector or Posture Validator always generated an error if it 2337 saw unexpected attributes, the attacker could cause failures and 2338 denial of service by adding attributes or messages to an 2339 exchange. 2341 5.2.6. Denial of Service 2343 A variety of types of denial of service attacks are possible 2344 against the PA-TNC message exchange if left unprotected to 2345 untrusted parties along the communication path between the 2346 Posture Collector and Posture Validator. Normally, the PT 2347 exchange is bi-directionally authenticated which helps to 2348 prevent a MiTM on the network from becoming an active proxy, but 2349 transparent message routing gateways may still exist on the 2350 communication path and can modify the integrity of the message 2351 exchange unless adequate integrity protection is provided. If 2352 the MiTM or other entities on the network can send messages to 2353 the Posture Broker Client or Posture Broker Server that appear 2354 to be part of an assessment, these messages could confuse the 2355 Posture Collector and Posture Validator or cause them to perform 2356 unnecessary work or take incorrect action. Several example 2357 denial of service situations are described in section 5.2.3 and 2358 5.2.5. Many potential denial of service examples exist, 2359 including flooding messages to Posture Collector or Posture 2360 Validator, sending very large messages containing many 2361 attributes, and repeatedly asking for resource intensive 2362 operations. 2364 6. Privacy Considerations 2366 The PA-TNC protocol is designed to allow for controlled 2367 disclosure of security relevant information about an endpoint, 2368 specifically for the purpose of enabling an assessment of the 2369 endpoint's compliance with network policy. The purpose of this 2370 protocol is to provide visibility into the state of the 2371 protective mechanisms on the endpoint, in order for the Posture 2372 Validators and Posture Broker Server to determine whether the 2373 endpoint is up to date and thus has the best chance of being 2374 resilient in the face of malware threats. One risk associated 2375 with providing visibility into the contents of an endpoint is 2376 the increased chance for exposure of privacy sensitive 2377 information without the consent of the user. 2379 While this protocol does provide the Posture Validator the 2380 ability to request specific information about the endpoint, the 2381 protocol is not open ended--bounding the Posture Validator to 2382 only query specific information (attributes) about specific 2383 security features (component types) of the endpoint. Each PA- 2384 TNC message is explicitly about a single component from the list 2385 of components in section 2.4. These components include a list 2386 of security-related aspects of the endpoint that affect the 2387 ability of the endpoint to resist attacks and thus are of 2388 interest during an assessment. Discretionary components used by 2389 the user to create or view content are not on the list, as they 2390 are more likely to have access to privacy sensitive information. 2391 Similarly, PA-TNC messages contain a set of attributes which 2392 describe the particular component. Each attribute contains 2393 generic information (e.g. product information or versions) about 2394 the component, so it is unlikely to include any user specific or 2395 identifying information. This combination of limited set of 2396 security related components with non-user specific attributes 2397 greatly reduces the risk of exposure of privacy sensitive 2398 information. Vendors that choose to define additional component 2399 types and/or attributes within their name space are encouraged 2400 to provide similar constraints. 2402 Even with the bounding of standard attribute information to 2403 specific components, it is possible that individuals might wish 2404 to share less information with different networks they wish to 2405 access. For example, a user may wish to share more information 2406 when connecting or being reassessed by the user's employer 2407 network than what would be made available to the local coffee 2408 shop wireless network. While these situations do not impact the 2409 protocol itself, they do suggest that Posture Collector 2410 implementations should consider supporting a privacy filter 2411 allowing the user and/or system owner to restrict access to 2412 certain attributes based upon the target network. The 2413 underlying PT protocol authenticates the network's Posture 2414 Broker Server at the start of an assessment, so identity can be 2415 made available to the Posture Collector and per-network privacy 2416 filtering is possible. Network owners should make available a 2417 list of the attributes they require to perform an assessment and 2418 any privacy policy they enforce when handling the data. Users 2419 wishing to use a more restricted privacy filter on the endpoint 2420 may risk not being able to pass an assessment and thus not gain 2421 access to the requested network or resource. 2423 7. IANA Considerations 2425 Two new IANA registries are defined by this specification: IETF 2426 Standard PA-TNC Attribute Types and IETF Standard PA-TNC Error 2427 Codes. This section explains how these registries work. Also, 2428 this specification defines nine new IETF Standard PA Subtypes. 2429 These assignments will be added to the registry for IETF 2430 Standard PA Subtypes when this document is approved by the IESG 2431 as an RFC. 2433 Section 7.1 defines the new IETF Standard PA Subtypes. Sections 2434 7.2 and 7.3 provide guidance to the IANA in creating and 2435 managing the two new IANA registries defined by this 2436 specification. 2438 7.1. New IETF Standard PA Subtypes 2440 Section 2.4 of this specification defines several new IETF 2441 Standard PA Subtypes. Here is a list of these assignments: 2443 Number Name 2444 ------ ---- 2445 0 Testing 2446 1 Operating System 2447 2 Anti-Virus 2448 3 Anti-Spyware 2449 4 Anti-Malware 2450 5 Firewall 2451 6 IDPS 2452 7 VPN 2454 Once this document becomes an RFC, these IETF Standard PA 2455 Subtypes should be added to the registry for IETF Standard PA 2456 Subtypes defined in the PB-TNC specification. The RFC number 2457 assigned to this document should be associated with these 2458 assignments. 2460 7.2. Registry for IETF Standard PA-TNC Attribute Types 2462 The name for this registry is "IETF Standard PA-TNC Attribute 2463 Types". Each entry in this registry should include a human- 2464 readable name, a decimal integer value between 0 and 2^32-1, and 2465 a reference to an RFC where the contents of this attribute type 2466 are defined. This RFC must define the meaning of this PA-TNC 2467 attribute type and the format and semantics of the PA-TNC 2468 Attribute Value field for PA-TNC attributes that include the 2469 designated numeric value in the PA-TNC Attribute Type field and 2470 the value 0 in the PA-TNC Attribute Vendor ID field. 2472 Entries to this registry may only be added by IETF Consensus, as 2473 defined in RFC 2434 [3]. That is, they can only be added in an 2474 RFC approved by the IESG. 2476 The following entries for this registry are defined in this 2477 document. Once this document becomes an RFC, they should become 2478 the initial entries in the registry for IETF Standard PA-TNC 2479 Attribute Types. 2481 Integer Value Name Defining RFC 2482 ------------- ---- ------------ 2483 0 Testing RFC # Assigned to this I-D 2484 1 Attribute Request RFC # Assigned to this I-D 2485 2 Product Information RFC # Assigned to this I-D 2486 3 Numeric Version RFC # Assigned to this I-D 2487 4 String Version RFC # Assigned to this I-D 2488 5 Operational Status RFC # Assigned to this I-D 2489 6 Port Filter RFC # Assigned to this I-D 2490 7 Installed Packages RFC # Assigned to this I-D 2491 8 PA-TNC Error RFC # Assigned to this I-D 2493 7.3. Registry for IETF Standard PA-TNC Error Codes 2495 The name for this registry is "IETF Standard PA-TNC Error 2496 Codes". Each entry in this registry should include a human- 2497 readable name, a decimal integer value between 0 and 2^32-1, and 2498 a reference to an RFC where this error code is defined. This 2499 RFC must define the meaning of this error code and the format 2500 and semantics of the Error Information field for PA-TNC 2501 attributes that have a PA-TNC Vendor ID of 0, a PA-TNC Attribute 2502 Type of PA-TNC Error, the designated numeric value in the PA-TNC 2503 Error Code field, and the value 0 in the PA-TNC Error Code 2504 Vendor ID field. 2506 Entries to this registry may only be added by IETF Consensus, as 2507 defined in RFC 2434. That is, they can only be added in an RFC 2508 approved by the IESG. 2510 The following entries for this registry are defined in this 2511 document. Once this document becomes an RFC, they should become 2512 the initial entries in the registry for IETF Standard PA-TNC 2513 Error Codes. 2515 Integer Value Name Defining RFC 2516 ------------- ---- ------------ 2517 1 Invalid Parameter RFC # Assigned to this I-D 2518 2 Version Not Supported RFC # Assigned to this I-D 2519 3 Attribute Type Not Supported RFC # For this I-D 2521 8. Acknowledgments 2523 The authors of this draft would like to acknowledge the 2524 following people who have contributed to or provided substantial 2525 input on the preparation of this document or predecessors to it: 2526 Stuart Bailey, Roger Chickering, Lauren Giroux, Charles 2527 Goldberg, Steve Hanna, Ryan Hurst, Meenakshi Kaushik, Greg 2528 Kazmierczak, Scott Kelly, PJ Kirner, Houcheng Lee, Lisa 2529 Lorenzin, Mahalingam Mani, Sung Lee, Ravi Sahita, Mauricio 2530 Sanchez, Brad Upson, and Han Yin. 2532 This document was prepared using 2-Word-v2.0.template.dot. 2534 9. References 2536 9.1. Normative References 2538 [1] Bradner, S., "Key words for use in RFCs to Indicate 2539 Requirement Levels", BCP 14, RFC 2119, March 1997. 2541 [2] F. Yergeau, "UTF-8, a transformation format of ISO 10646", 2542 RFC 3629, November 2003. 2544 [3] Alvestrand, H. and T. Narten, "Guidelines for Writing an 2545 IANA Considerations Section in RFCs", RFC 2434, October 2546 1998. 2548 [4] Klyne, G. and C. Newman, "Date and Time on the Internet: 2549 Timestamps", RFC 3339, July 2002. 2551 [5] Sahita, R., Hanna, S., and R. Hurst, "PB-TNC: A Posture 2552 Broker Protocol (PB) Compatible with TNC", draft-sahita- 2553 nea-pb-00.txt, Work In Progress, February 2008. 2555 9.2. Informative References 2557 [6] Trusted Computing Group, "IF-M: TLV Binding", February 2558 2008. 2560 [7] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 2561 Tardo, "Network Endpoint Assessment (NEA): Overview and 2562 Requirements", draft-ietf-nea-requirements-05.txt, Work In 2563 Progress, November 2007. 2565 [8] Sangster, P., "PA-TNC Security: A Posture Attribute (PA) 2566 Security Protocol Compatible with TNC", draft-sangster- 2567 nea-pa-tnc-security-00.txt, Work In Progress, February 2568 2008. 2570 Author's Address 2572 Paul Sangster 2573 Symantec Corporation 2574 6825 Citrine Drive 2575 Carlsbad, CA 92009 USA 2576 Phone: +1.760.438.5656 2577 Email: Paul_Sangster@symantec.com 2579 Intellectual Property Statement 2581 The IETF takes no position regarding the validity or scope of 2582 any Intellectual Property Rights or other rights that might be 2583 claimed to pertain to the implementation or use of the 2584 technology described in this document or the extent to which any 2585 license under such rights might or might not be available; nor 2586 does it represent that it has made any independent effort to 2587 identify any such rights. Information on the procedures with 2588 respect to rights in RFC documents can be found in BCP 78 and 2589 BCP 79. 2591 Copies of IPR disclosures made to the IETF Secretariat and any 2592 assurances of licenses to be made available, or the result of an 2593 attempt made to obtain a general license or permission for the 2594 use of such proprietary rights by implementers or users of this 2595 specification can be obtained from the IETF on-line IPR 2596 repository at http://www.ietf.org/ipr. 2598 The IETF invites any interested party to bring to its attention 2599 any copyrights, patents or patent applications, or other 2600 proprietary rights that may cover technology that may be 2601 required to implement this standard. Please address the 2602 information to the IETF at ietf-ipr@ietf.org. 2604 Disclaimer of Validity 2606 This document and the information contained herein are provided 2607 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2608 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 2609 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 2610 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 2611 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 2612 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 2613 OR FITNESS FOR A PARTICULAR PURPOSE. 2615 Copyright Statement 2617 Copyright (C) The IETF Trust (2008). 2619 This document is subject to the rights, licenses and 2620 restrictions contained in BCP 78, and except as set forth 2621 therein, the authors retain all their rights. 2623 Acknowledgment 2625 Funding for the RFC Editor function is currently provided by the 2626 Internet Society.