idnits 2.17.1 draft-sangster-nea-pt-tls-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 3, 2011) is 4801 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 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-01) exists of draft-salowey-nea-asokan-00 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P. Sangster 2 Internet Draft Symantec Corporation 3 Intended status: Proposed Standard March 3, 2011 4 Expires: September 2011 6 PT-TLS: A Posture Transport (PT) Protocol Compatible with TNC Using 7 Transport Layer Security (TLS) 8 draft-sangster-nea-pt-tls-02.txt 10 Abstract 12 This document specifies PT-TLS, a Posture Transport (PT) protocol 13 compatible with the Trusted Computing Group's IF-T Binding to TLS 1.0 14 protocol. The document then evaluates PT-TLS against the 15 requirements defined in the NEA Overview and Requirements and PB-TNC 16 specifications. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 This Internet-Draft will expire on September 3, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. 53 Table of Contents 55 1. Introduction...................................................4 56 1.1. Prerequisites.............................................4 57 1.2. Message Diagram Conventions...............................4 58 1.3. Conventions used in this document.........................5 59 2. Design Considerations..........................................5 60 2.1. Benefits of TCP/IP Connectivity...........................5 61 2.2. Leveraging Proven TLS Security............................6 62 2.3. TLV-Oriented Based Message Encapsulation..................6 63 2.4. No Change to Base TLS Protocol............................7 64 3. PT-TLS Protocol................................................7 65 3.1. Initiating a PT-TLS Session...............................8 66 3.1.1. Issues with Server Initiated PT-TLS Sessions.........8 67 3.1.2. Establish or Re-Use Existing PT-TLS Session..........9 68 3.2. TCP Port Usage............................................9 69 3.3. Preventing MITM Attacks with Channel Bindings.............9 70 3.4. PT-TLS Message Flow......................................10 71 3.4.1. Assessment Triggers.................................10 72 3.4.2. PT-TLS Message Exchange Phases......................10 73 3.4.2.1. TLS Setup Phase................................11 74 3.4.2.2. PT-TLS Negotiation Phase.......................12 75 3.4.2.3. PT-TLS Data Transport Phase....................13 76 3.4.3. TLS Requirements....................................13 77 3.5. PT-TLS Message Format....................................14 78 3.6. IETF Standard PT-TLS Message Types.......................16 79 3.7. PT-TLS Version Negotiation...............................19 80 3.7.1. Version Request Message.............................19 81 3.7.2. Version Response Message............................21 82 3.8. Client Authentication Message Exchange...................21 83 3.8.1. Client Authentication Request Message...............23 84 3.8.1.1. Auth Type Values...............................24 85 3.8.2. Client Authentication Selection Message.............25 86 3.8.3. Client Authentication Challenge Message.............26 87 3.8.3.1. Basic Authentication Challenge.................27 88 3.8.4. Client Authentication Response Message..............28 89 3.8.4.1. Basic Authentication Information...............29 90 3.8.5. Client Authentication Successful Message............30 91 3.9. Error Message............................................30 93 4. Security Considerations.......................................34 94 4.1. Trust Relationships......................................34 95 4.1.1. Posture Transport Client............................34 96 4.1.2. Posture Transport Server............................35 97 4.2. Security Threats and Countermeasures.....................36 98 4.2.1. Message Theft.......................................36 99 4.2.2. Message Fabrication.................................37 100 4.2.3. Message Modification................................38 101 4.2.4. Denial of Service...................................38 102 4.2.5. NEA Asokan Attacks..................................38 103 5. Privacy Considerations........................................39 104 6. IANA Considerations...........................................39 105 6.1. Designated Expert Guidelines.............................40 106 6.2. Registry for PT-TLS Message Types........................41 107 6.3. Registry for PT-TLS Error Codes..........................42 108 6.4. Registry for PT-TLS Auth Types...........................43 109 7. Acknowledgments...............................................43 110 8. References....................................................44 111 8.1. Normative References.....................................44 112 8.2. Informative References...................................44 113 Appendix A. Evaluation Against NEA Requirements..................46 114 A.1. Evaluation Against Requirement C-1.......................46 115 A.2. Evaluation Against Requirements C-2......................46 116 A.3. Evaluation Against Requirements C-3......................46 117 A.4. Evaluation Against Requirements C-4......................46 118 A.5. Evaluation Against Requirements C-5......................47 119 A.6. Evaluation Against Requirements C-6......................47 120 A.7. Evaluation Against Requirements C-7......................48 121 A.8. Evaluation Against Requirements C-8......................48 122 A.9. Evaluation Against Requirements C-9......................48 123 A.10. Evaluation Against Requirements C-10....................49 124 A.11. Evaluation Against Requirements C-11....................49 125 A.12. Evaluation Against Requirements PT-1....................49 126 A.13. Evaluation Against Requirements PT-2....................50 127 A.14. Evaluation Against Requirements PT-3....................50 128 A.15. Evaluation Against Requirements PT-4....................50 129 A.16. Evaluation Against Requirements PT-5....................50 130 A.17. Evaluation Against Requirements PT-6 (from PB-TNC 131 specification)................................................51 132 A.18. Evaluation Against Requirements PT-7 (from PB-TNC 133 specification)................................................51 134 A.19. Evaluation Against Requirements PT-8 (from PB-TNC 135 specification)................................................51 136 A.20. Evaluation Against Requirements PT-9 (from PB-TNC 137 specification)................................................51 139 1. Introduction 141 This document specifies PT-TLS, a Posture Transport (PT) protocol 142 compatible with the Trusted Computing Group's IF-T Binding to TLS 1.0 143 protocol [IFT-TLS]. The document then evaluates PT-TLS against the 144 applicable requirements defined in the NEA Overview and Requirements 145 [RFC5209] and PB-TNC [RFC5793] specifications. 147 NEA protocols are intended to be used for pre-admission assessment of 148 endpoints joining the network and to assess endpoints already present 149 on the network. In order to support both usage models, two different 150 types (or bindings) of PT protocols are necessary to operate before 151 and after the endpoint has an assigned IP address and other network 152 layer information. This specification focuses on the PT protocol 153 used to assess endpoints already present on the network and thus is 154 able to use TCP/IP based transport protocols. 156 The PT protocol in the NEA architecture is responsible for 157 transporting PB-TNC batches (often containing PA-TNC [RFC5792] 158 attributes) over the network between the Posture Transport Client 159 component of the NEA Client and the Posture Transport Server 160 component of the NEA Server. The PT protocol also offers strong 161 security protections to ensure the exchanged messages are protected 162 from a variety of threats from hostile intermediaries. 164 1.1. Prerequisites 166 This document does not define an architecture or reference model. 167 Instead, it defines one binding of the PT protocol that works within 168 the reference model described in the NEA Overview and Requirements 169 specification. The reader is assumed to be thoroughly familiar with 170 the NEA Overview and Requirements specification. No familiarity with 171 TCG specifications is assumed. 173 1.2. Message Diagram Conventions 175 This specification defines the syntax of PT-TLS messages using 176 diagrams. Each diagram depicts the format and size of each field in 177 bits. Implementations MUST send the bits in each diagram as they are 178 shown, traversing the diagram from top to bottom and then from left 179 to right within each line (which represents a 32-bit quantity). 180 Multi-byte fields representing numeric values must be sent in network 181 (big endian) byte order. 183 Descriptions of bit field (e.g. flag) values are described referring 184 to the position of the bit within the field. These bit positions are 185 numbered from the most significant bit through the least significant 186 bit so a one octet field with only bit 0 set has the value 0x80. 188 1.3. Conventions used in this document 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 192 document are to be interpreted as described in RFC 2119 [RFC2119]. 194 2. Design Considerations 196 This section discusses some of the key design considerations for the 197 PT protocol. This document specifies the PT binding for use when 198 performing an assessment or reassessment after the endpoint has been 199 admitted to the network and is capable of using TCP/IP to communicate 200 with the NEA Server. If the endpoint does not yet have TCP/IP layer 201 access to the NEA Server (and vice versa), the endpoint should use 202 the PT-EAP (Posture Transport (PT) Protocol for EAP Tunnel Methods) 203 [PT-EAP] protocol when performing an assessment. 205 Because the endpoint has TCP/IP access to the NEA Server (potentially 206 on a restricted portion of the network), the NEA Client and NEA 207 Server have the ability to establish (or re-use) a reliable TCP/IP 208 connection in order to perform the assessment. The TCP/IP connection 209 enables the assessment to occur over a relatively high performance, 210 reliable channel capable of supporting multiple roundtrip message 211 exchanges in full duplex manner. These connection properties are 212 very different from what is available when the endpoint is initially 213 joining the network (e.g. during an 802.1X based assessment), 214 therefore the design described in this specification follows a 215 different path to maximize the benefits of the underlying TCP/IP 216 connection. 218 2.1. Benefits of TCP/IP Connectivity 220 The PT protocol is typically able to offer to the NEA Client and NEA 221 Server significantly higher quality of service and flexibility of 222 operation than link layer oriented bindings such as PT-EAP (Posture 223 Transport (PT) Protocol for EAP Tunnel Methods). However, there may 224 be some added risks when the endpoint is on the network prior to its 225 initial assessment (if no admission time assessment had been 226 performed). Because of these risks, the combined use of an EAP-based 227 assessment during admission followed by reassessment using TCP/IP may 228 be appropriate in some environments. 229 Some of the benefits to having a TCP/IP based transport during an 230 assessment include: 232 o Full Duplex connectivity - can send multiple assessment messages 233 prior to receiving a response including sending of asynchronous 234 messages (e.g. alerts of posture or policy changes) 236 o High Bandwidth - potentially much higher bandwidth than other 237 transports (e.g. EAP) allowing more in-band data (e.g. 238 remediation, verbose posture information) 240 o Large Messages - ability to send very large PA messages without 241 directly fragmenting them (underlying carrier protocol may 242 introduce fragmentation) 244 o Bi-directional - NEA Client and NEA Server can initiate an 245 assessment or reassessment 247 o Multiple Roundtrips - NEA Client and NEA Server can exchange 248 numerous messages without fear of infrastructure timeouts. 249 However, the entire exchange should be kept as brief as possible 250 if the user has to wait for its completion. 252 2.2. Leveraging Proven TLS Security 254 All PT protocol bindings must be capable of providing strong 255 authentication, integrity and confidentiality protection for the PB- 256 TNC batches. Rather than define a new protocol over TCP/IP to 257 provide adequate protection, this specification requires the use of 258 Transport Layer Security [RFC5246] to secure the connection. TLS was 259 selected because it's a widely deployed protocol with parallel 260 protections to a number of the EAP tunnel methods, and it meets all 261 of the security requirements. 263 2.3. TLV-Oriented Based Message Encapsulation 265 The design of the PT-TLS protocol is based upon the use of type- 266 length-value (TLV) oriented protocol message that identifies the type 267 of message, the message's length and a potentially variable length 268 payload value. The use of a TLV orientated encoding was chosen to 269 match the Internet standard PA-TNC and PB-TNC protocols. Because the 270 PA-TNC, PB-TNC and PT-TLS protocols are typically implemented inside 271 the same process space, this allows a common set of message parsing 272 code to be used. Similarly creation of debugging tools is simplified 273 by the common encoding methodologies. TLV-based encoding was used in 274 each of the NEA protocols in part because it enables a very space 275 efficient representation on the network and is simpler to parse than 276 some other encodings to benefit lower powered (or battery 277 constrained) devices. 279 2.4. No Change to Base TLS Protocol 281 During the design of the PT-TLS protocol, several approaches were 282 considered with different costs and benefits. Several considered 283 approaches involved integrating the PT protocol into the TLS 284 handshake protocol. Because the PT protocol requires the underlying 285 TLS carrier to provide security protections, the PT protocol couldn't 286 operate before the cipher suites were negotiated and in use. One 287 option was to integrate into the TLS handshake protocol after the 288 ChangeCipherSpec phase allowing the PT message to be protected. The 289 benefit of this approach is that the assessment protocol could 290 operate below the application protocols allowing for easier 291 integration into applications. However, making this change would 292 require some extensions to the TLS handshake protocol standards and 293 existing widely deployed TLS implementations, so it wasn't clear that 294 the cost was warranted, particularly because the application 295 independence can also be offered by a shim library between the 296 application and TLS library that provides the PT protocol 297 encapsulation/decapsulation. 299 The other general approach considered was to have PT-TLS layer on top 300 of TLS as an application protocol (using the standard 301 application_data ContentType). This has the advantage that existing 302 TLS software could be used. However, the PB-TNC traffic would need 303 to be encapsulated/decapsulated by a new PT-TLS protocol layer before 304 being passed to the TLS library. This didn't seem like a significant 305 issue as PB-TNC is architected to layer on PT anyway. 307 After considering the different options, it was determined that 308 layering the PT protocol on top of the TLS protocol without requiring 309 current TLS protocol implementations to change met all the 310 requirements and offered the best path toward rapid adoption and 311 deployment. Therefore the following sections describe a PT protocol 312 that is carried on top of TLS. 314 3. PT-TLS Protocol 316 This section specifies the PT-TLS protocol, a Posture Transport (PT) 317 protocol carried by the Transport Layer Security (TLS) protocol over 318 a TCP/IP network. This protocol runs directly on top of TLS as an 319 application. This means PT-TLS is encapsulated within the TLS Record 320 Layer protocol using the standard ContentType for applications 321 (application_data). 323 3.1. Initiating a PT-TLS Session 325 The PT-TLS protocol may be initiated by a Posture Transport Client or 326 a Posture Transport Server. This flexibility supports different use 327 cases. For example, a Posture Transport Client that wishes to 328 trigger a NEA assessment to determine whether its security posture is 329 good can start up a PT-TLS session and request a posture assessment. 330 On the other hand, when an endpoint requests access to a protected 331 network or resource, a Posture Transport Server can start up a PT-TLS 332 session and perform a posture assessment before deciding whether to 333 grant access. 335 The party that initiates a PT-TLS session is known as the "PT-TLS 336 session initiator". The other party in the session (which receives 337 the request to open a PT-TLS session) is known as the "PT-TLS session 338 responder". 340 3.1.1. Issues with Server Initiated PT-TLS Sessions 342 In order for a NEA Server to establish a PT-TLS session, the NEA 343 Client needs to be listening for a connection request on a TCP port 344 known by the NEA Server. In many deployments, the security policies 345 (e.g. firewall software) of an endpoint are designed to minimize the 346 number of open inbound TCP/UDP ports that are available to the 347 network to reduce the potential attack footprint. This is one issue 348 that makes it difficult for a NEA Server to initiate a PT-TLS 349 session. 351 Another issue with this scenario involves X.509 certificates. When 352 the NEA Server creates a TLS session to the NEA Client, the NEA 353 Client is effectively acting as the TLS server during the TLS 354 protocol exchange. This means the NEA Client would typically need to 355 possess an X.509 certificate to protect the initial portion of the 356 TLS handshake. In situations where the NEA Server initiates the 357 creation of the TLS session, both the NEA Client and NEA Server MUST 358 possess X.509 certificates to fully authenticate the session. For 359 many deployments, provisioning X.509 certificates to all NEA Clients 360 has scalability and cost issues; therefore, it is recommended that 361 the NEA Client not listen for connection requests from the NEA Server 362 but instead establish and maintain a TLS session to the NEA Server 363 proactively, so either party can initiate an assessment using the 364 preexisting TLS session as required. 366 Therefore, NEA Clients SHOULD be capable of establishing and holding 367 open a TLS session with the NEA Server immediately after obtaining 368 network access. A NEA Client MAY listen for connection requests from 369 the NEA Server and establish a new PT-TLS session when one does not 370 already exist. Having an existing PT-TLS session allows either party 371 to initiate an assessment without requiring the NEA Client to be 372 listening for new connection requests. 374 3.1.2. Establish or Re-Use Existing PT-TLS Session 376 A single PT-TLS session can support multiple NEA assessments, which 377 can be started by either party (the PT-TLS session initiator or the 378 PT-TLS session responder). The party that starts a NEA assessment is 379 known as the "assessment initiator" and the other party is known as 380 the "assessment responder". 382 If the assessment initiator already has a PT-TLS session to the 383 assessment responder, the initiator can re-use this session; 384 otherwise, a new PT-TLS session must be established. 386 3.2. TCP Port Usage 388 In order for a PT-TLS session initiator to establish a TCP connection 389 to a PT-TLS session responder, the initiator needs to know the TCP 390 port number on which the responder is listening for assessment 391 requests. Therefore, this specification requests the IANA reserve a 392 well known TCP port number for use with the PT-TLS protocol upon 393 publication of this specification as an Internet standard RFC. 395 3.3. Preventing MITM Attacks with Channel Bindings 397 As described in the NEA Asokan Attack Analysis [ASOKAN], a 398 sophisticated MITM attack can be mounted against NEA systems. The 399 attacker forwards PA-TNC messages from a healthy machine through an 400 unhealthy one so that the unhealthy machine can gain network access. 401 Because there are easier attacks on NEA systems, like having the 402 unhealthy machine lie about its configuration, this attack is 403 generally only mounted against machines with an External Measurement 404 Agent (EMA). The EMA is a separate entity, difficult to compromise, 405 which measures and attests to the configuration of the endpoint. 407 To protect against NEA Asokan attacks, the Posture Broker on an EMA- 408 equipped endpoint should pass the tls-unique channel binding 409 [RFC5929] for PT-TLS's underlying TLS session to the EMA. This value 410 can then be included in the EMA's attestation and the Posture 411 Validator responsible for communicating with the EMA may then confirm 412 that the value matches the tls-unique channel binding for its end of 413 the connection. If the values match, the posture sent by the EMA and 414 NEA Client is from the same endpoint as the client side of the TLS 415 connection (since the endpoint knows the tls-unique value), so no 416 man-in-the-middle is forwarding posture. If they differ, an attack 417 has been detected. The Posture Validator SHOULD fail its 418 verification of the endpoint if an attack has been detected. 420 3.4. PT-TLS Message Flow 422 This section discusses the general flow of messages between the NEA 423 Client's Posture Transport Client and the NEA Server's Posture 424 Transport Server in order to perform NEA assessments using the PT-TLS 425 protocol. 427 3.4.1. Assessment Triggers 429 Initially, the NEA Client or NEA Server will decide that an 430 assessment is needed. What stimulates the decision to perform an 431 assessment is outside the scope of this specification, but some 432 examples include: 433 o NEA Server becoming aware of suspicious behavior on an endpoint 434 o NEA Server receiving new policies requiring immediate action 435 o NEA Client noticing a change in local security posture 436 o NEA Client wishing to access a protected network or resource 438 Because either the NEA Client or NEA Server can trigger the 439 establishment of the TLS session and initiate the assessment, this 440 document will use the terms "assessment initiator" and the 441 "assessment responder". This nomenclature allows either NEA 442 component to fill either of the PT-TLS roles. 444 3.4.2. PT-TLS Message Exchange Phases 446 The PT-TLS message exchange occurs in three distinct phases: 447 o TLS Setup (including TLS Handshake protocol) 448 o PT-TLS Negotiation 449 o PT-TLS Data Transport 451 The TLS Setup phase is responsible for the establishment of the TCP 452 connection and the TLS protections for the PT-TLS messages. The TLS 453 Setup phase normally starts with the establishment of a TCP 454 connection between the Posture Transport Client and Posture Transport 455 Server. The new connection triggers the TLS Handshake protocol to 456 establish the cryptographic protections for the TLS session. The TLS 457 Setup phase SHOULD NOT be repeated after the PT-TLS Data Transport 458 phase has been reached unless a change of TLS cipher suite or keying 459 material is required to properly protect the session. This phase 460 also enables the establishment of the tls-unique shared secret that 461 can be used in a later phase to bind the posture sent with this TLS 462 connection. 464 The PT-TLS Negotiation phase is only performed at the start of the 465 first assessment on a TLS session. During this phase, the NEA Client 466 and NEA Server discover each other's PT-TLS capabilities and 467 establish a context that will apply to all future PT-TLS messages 468 sent over the TLS session. The PT-TLS Negotiation phase MUST NOT be 469 repeated after the session has entered the Data Transport phase. NEA 470 assessment messages (PB-TNC batches) MUST NOT be sent by the NEA 471 Client or NEA Server prior to the completion of the PT-TLS 472 Negotiation phase to ensure that the security protections for the 473 session are properly established and applied to the NEA assessment 474 messages. 476 Finally the Data Transport phase allows the NEA Client and NEA Server 477 to exchange PT messages under the protection of the TLS session 478 consistent with the capabilities established in earlier phases. The 479 exchanged messages can be a PT-TLS protected NEA assessment as 480 described in this specification or other vendor-defined PT-TLS 481 exchanged messages. 483 3.4.2.1. TLS Setup Phase 485 After a new TCP connection is established between the Posture 486 Transport Client and Posture Transport Server, a standard TLS 487 exchange is performed to negotiate a common security context for 488 protecting subsequent communications. As discussed in section 3.4.1. 489 , the TCP connection establishment and/or the TLS handshake protocol 490 could be initiated by either the NEA Client or NEA Server. The most 491 common situation would be for the assessment initiator to trigger the 492 creation of the TCP connection and TLS handshake, so an assessment 493 could begin when no session already exists. When the NEA Server has 494 initiated the TLS Setup, the NEA Server is acting as a TLS client and 495 the NEA Client is the TLS server (accepting the inbound TLS session 496 request). The expected normal case is that the NEA Client initiates 497 this phase, so that the NEA Server is acting as the TLS server and 498 therefore the bootstrapping of the security of the TLS session is 499 using the NEA Server's certificate. Having the NEA Client initiate 500 the TLS session avoids the need for the NEA Client to also possess a 501 certificate. 503 During the TLS Setup phase of PT-TLS, the PT-TLS session initiator 504 contacts the listening port of the TLS session responder and performs 505 a TLS handshake. The PT-TLS session responder MUST possess a 506 trustworthy X.509 certificate used to authenticate to the TLS 507 initiator and used to bootstrap the security protections of the TLS 508 session. The PT-TLS session initiator MAY also use an X.509 509 certificate to authenticate to the PT-TLS session responder providing 510 for a bi-directional authentication of the PT-TLS session. 511 Due to deployment issues with issuing and distributing certificates 512 to a potentially large number of NEA Clients, this specification 513 allows the NEA Client to be authenticated during the PT-TLS 514 Negotiation phase using other more cost effective methods. At the 515 conclusion of a successful initial TLS Setup phase, the NEA Client 516 and NEA Server have a protected session to exchange messages. This 517 allows the protocol to transition to the PT-TLS Negotiation phase. 519 3.4.2.2. PT-TLS Negotiation Phase 521 Once a TLS session has been established between Posture Transport 522 Client and Posture Transport Server, the PT-TLS session initiator 523 sends a Version Request Message indicating it is supported PT-TLS 524 protocol version range. Next, the PT-TLS session responder sends a 525 Version Response Message which selects a protocol version from within 526 the range offered. The PT-TLS session responder SHOULD select the 527 preferred version offered if supported; otherwise, the highest 528 version that the responder is able to support from the received 529 Version Request Message. If the PT-TLS session responder is unable or 530 unwilling to support any of the versions included in the Version 531 Request Message, the responder SHOULD send a Version Not Supported 532 error message. 534 If no client side authentication has occurred during the TLS Setup 535 phase, the Posture Transport Server can authenticate the client using 536 PT-TLS client authentication messages. If the Posture Transport 537 Server wishes to trigger a client authentication exchange, the 538 Posture Transport Server SHOULD send a Client Authentication Request 539 message (see section 3.8.1. for details). The Posture Transport 540 Server MAY skip the Client Authentication Request exchange and 541 instead start with the client authentication by sending a Client 542 Authentication Challenge message if it only supports one type of 543 authentication. 545 When the Posture Transport Client receives the Client Authentication 546 Request, the Posture Transport Client responds with a Client 547 Authentication Selection message indicating the method of 548 authentication to be used. Upon selecting an appropriate 549 authentication method, the Posture Transport Server requests the 550 client's identity and authenticator information using the PT-TLS 551 Client Authentication Challenge message. The Posture Transport 552 Client responds with the requested information following the selected 553 authentication scheme in a Client Authentication Response message. 554 The Posture Transport Client and Server might exchange multiple 555 roundtrips of client authentication messages in order to perform the 556 authentication depending on the type of authentication selected. 557 When the client authentication successfully completes, the PT-TLS 558 session transitions into the Data Transport phase, where it will 559 remain for the duration of the session. 561 3.4.2.3. PT-TLS Data Transport Phase 563 Once a PT-TLS session is available to carry NEA assessments, either 564 the Posture Transport Client or Server can start an assessment when 565 provided a PB-TNC batch for transmission. The assessment initiator 566 first envelopes the PB-TNC batch in a PT-TLS message, then assigns a 567 message identifier to the message and finally transmits it over the 568 session. The assessment responder validates the PT-TLS message and 569 delivers the encapsulated PB-TNC batch to its upstream component 570 (Posture Broker Client or Server). 572 Most PT-TLS messages contain PB-TNC batches that house PA-TNC 573 requests for posture information or a response containing the 574 requested posture information. The Posture Transport Client and 575 Posture Transport Server may also exchange messages between them, 576 such as a PT-TLS Error Message indicating that a problem occurred 577 processing a message. During an assessment, the Posture Transport 578 Client and Server merely encapsulate and exchange the PB-TNC batches 579 and are unaware of the state of the assessment. 581 The PT-TLS protocol allows either party to send a PT-TLS message at 582 any time, reflecting the full duplex nature of the underlying TLS 583 session. For example, an assessment initiator may send several PT- 584 TLS messages prior to receiving any responses from the assessment 585 responder. All implementations of PT-TLS MUST support full duplex 586 PT-TLS message exchange. However, some NEA protocols may not be able 587 to make use of the full-duplex message exchange. 589 3.4.3. TLS Requirements 591 In order to ensure that strong security is always available for 592 deployers and to improve interoperability, this section discusses 593 some requirements on the underlying TLS transport used by PT-TLS. 594 Implementations of PT-TLS MUST support use of TLS 1.1 [RFC4346] and 595 SHOULD also include support for TLS 1.2 [RFC5246]. For each TLS 596 version supported, implementations of the PT-TLS MUST at least 597 support the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite. This cipher 598 suite requires the server to provide a certificate that can be used 599 during the key exchange. Implementations SHOULD NOT include support 600 for cipher suites that do not minimally offer PT-TLS session 601 responder (typically Posture Transport Server) authentication, such 602 as the anonymous Diffie-Hellman cipher suites (e.g. 603 TLS_DH_anon_WITH_AES_128_CBC_SHA). 605 3.5. PT-TLS Message Format 607 This section describes the format and semantics of the PT-TLS 608 message. Every message sent over a PT-TLS session MUST start with 609 the PT-TLS header described in this section. 610 The following is the PT-TLS header: 612 1 2 3 613 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 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Reserved | Message Type Vendor ID | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Message Type | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Message Length | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Message Identifier | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Message Value (e.g. PB-TNC Batch) . . . | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 Reserved 628 Reserved for future use. This field MUST be set to 0 on 629 transmission and ignored upon reception. 631 Message Type Vendor ID 633 This field indicates the owner of the name space associated with 634 the Message Type. This is accomplished by specifying the 24 bit 635 SMI Private Enterprise Number (Vendor ID) of the party who owns 636 the Message Type name space. IETF Standard PT-TLS Message Types 637 MUST use zero (0) in this field. 639 The PT-TLS Message Type Vendor ID 0xffffff is reserved. Posture 640 Transport Clients and Servers MUST NOT send PT-TLS messages in 641 which the PT-TLS Message Type Vendor ID has this reserved value 642 (0xffffff). If a Posture Transport Client or Posture Transport 643 Server receives a message containing this reserved value 644 (0xffffff) in the PT-TLS Message Type Vendor ID, the recipient 645 SHOULD respond with an Invalid Parameter error code in a PT-TLS 646 Error message. 648 Message Type 649 This field defines the type of the PT-TLS message within the 650 scope of the specified Message Type Vendor ID that is included in 651 the Message Value field. The specific IETF standard values 652 allowable in this field when the Message Type Vendor ID is the 653 IETF SMI Private Enterprise Number value (0) are defined in 654 section 3.6. Recipients of a message containing a Message Type 655 Vendor ID and Message Type that is unrecognized SHOULD respond 656 with a Type Not Supported error code in a PT-TLS Error message. 658 Posture Transport Clients and Posture Transport Servers MUST NOT 659 require support for particular vendor-defined PT-TLS Message 660 Types and MUST interoperate with other parties despite any 661 differences in the set of vendor-defined PT-TLS Message Types 662 supported (although they MAY permit administrators to configure 663 them to require support for specific vendor-defined PT-TLS 664 message types). 666 If the PT-TLS Message Type Vendor ID field has the value zero 667 (0), then the PT-TLS Message Type field contains an IETF Standard 668 PT-TLS Message Type, as listed in the IANA registry. IANA 669 maintains a registry of PT-TLS Message Types. Entries in this 670 registry are added by Expert Review with Specification Required, 671 following the guidelines in section 6.1. Section 3.6. of this 672 specification defines the initial set of IETF Standard PT-TLS 673 Message Types. 675 The PT-TLS Message Type 0xffffffff is reserved. Posture 676 Transport Clients and Posture Transport Servers MUST NOT send PT- 677 TLS messages in which the PT-TLS Message Type has this reserved 678 value (0xffffffff). If a Posture Transport Client or Posture 679 Transport Server receives a message in which the PT-TLS Message 680 Type has this reserved value (0xffffffff), it SHOULD respond with 681 an Invalid Parameter error code in a PT-TLS Error message. 683 Message Length 685 This field contains the length in octets of the entire PT-TLS 686 message (including the entire header). Therefore, this value 687 MUST always be at least 16. Any Posture Transport Client or 688 Posture Transport Server that receives a message with a PT-TLS 689 Message Length field whose value is less than 16 SHOULD respond 690 with an Invalid Parameter PT-TLS error code. Similarly, if a 691 Posture Transport Client or Posture Transport Server receives a 692 PT-TLS message for a Message Type that has a known Message Length 693 and the Message Length indicates a different value (greater or 694 less than the expected value), the recipient SHOULD respond with 695 an Invalid Parameter PT-TLS error code. 697 Message Identifier 699 This field contains a value that uniquely identifies the PT-TLS 700 message on a per message sender (Posture Transport Client or 701 Server) basis. This value can be copied into the body of a 702 response message to indicate which message was received and 703 caused the response. For example, this field is included in the 704 PT-TLS Error Message so the recipient can determine which message 705 sent caused the error. 707 The Message Identifier MUST be a monotonically increasing counter 708 starting at zero indicating the number of the messages the sender 709 has transmitted over the TLS session. It is possible that a busy 710 or long lived session might exceed 2^32-1 messages sent, so the 711 message sender MUST roll over to zero upon reaching the 2^32nd 712 message, thus restarting the increasing counter. During a 713 rollover, it is feasible that the message recipient could be 714 confused if it keeps track of every previously received Message 715 Identifier, so recipients MUST be able to handle roll over 716 situations without generating errors. 718 Message Value 720 The contents of this field vary depending on the particular 721 Message Type Vendor ID and Message Type given in the PT-TLS 722 header for this PT-TLS message. This field most frequently 723 contains a PB-TNC batch. The contents of this field for each of 724 the IETF Standard PT-TLS Message Types are defined in this 725 specification. 727 3.6. IETF Standard PT-TLS Message Types 729 This section defines the NEA standard PT-TLS Message Types used to 730 carry PT-TLS messages and PB-TNC batches between the Posture 731 Transport Client and Posture Transport Server. 733 The following table summarizes the initial set of IETF standard 734 message type values, which are used with the PT-TLS Message Type 735 Vendor ID field set to the IETF SMI PEN (0). 737 Value (Name) Definition 738 ------------ ---------- 739 0 (Experimental) Reserved for experimental use. This 740 type will not offer interoperability 741 but allows for experimentation. This 742 message type MUST only be sent when 743 the NEA Client and NEA Server are in 744 the Data Transport phase and only on a 745 restricted, experimental network. 746 Production code MUST send an Invalid 747 Message error code in a PT-TLS Error 748 message if an Experimental message is 749 received. 751 1 (Version Request) Version negotiation request including 752 the range of versions supported by the 753 sender. This message type MUST only 754 be sent by the TLS session initiator 755 as the first PT-TLS message in the PT- 756 TLS Negotiation phase. Recipients 757 MUST send an Invalid Message error 758 code in a PT-TLS Error message if a 759 Version Request is received at another 760 time. 762 2 (Version Response) PT-TLS protocol version selected by 763 the responder. This message type MUST 764 only be sent by the TLS session 765 responder as the second message in the 766 PT-TLS Negotiation phase. Recipients 767 MUST send an Invalid Message error 768 code in a PT-TLS Error message if a 769 Version Response is received at 770 another time. 772 3 (Client Auth Request) Request for authentication of client 773 (PT-TLS session initiator). This 774 message includes the PT-TLS session 775 responder's supported set of 776 authentication methods. This message 777 can be used to start an authentication 778 of the PT-TLS session initiator. This 779 message type MUST only be sent by the 780 PT-TLS session initiator in the PT-TLS 781 Negotiation phase. Recipients MUST 782 send an Invalid Message error code in 783 a PT-TLS Error message if a Client 784 Auth Request message is received at 785 another time. 787 4 (Client Auth Selection) Authentication method selected by PT- 788 TLS session initiator. This message 789 type MUST only be sent by the PT-TLS 790 session initiator in response to a 791 Client Auth Request message sent in 792 the PT-TLS Negotiation phase. 793 Recipients MUST send an Invalid 794 Message error code in a PT-TLS Error 795 message if a Client Auth Selection 796 message is received at another time. 798 5 (Client Auth Challenge) Client authentication challenge from 799 the PT-TLS session responder (normally 800 NEA Server). This message type MUST 801 only be sent by the PT-TLS session 802 responder in the PT-TLS Negotiation 803 phase. Recipients MUST send an 804 Invalid Message error code in a PT-TLS 805 Error message if a Client Auth 806 Challenge is received after the PT-TLS 807 Negotiation phase. 809 6 (Client Auth Response) Identity and authenticator information 810 from the PT-TLS session initiator 811 (normally NEA Client). This message 812 type MUST only be sent by the PT-TLS 813 session initiator in the PT-TLS 814 Negotiation phase. Recipients MUST 815 send an Invalid Message error code in 816 a PT-TLS Error message if a Client 817 Auth Response message is received 818 after the PT-TLS Negotiation phase. 820 7 (Client Auth Success) Indication that client authentication 821 was completed successfully so PT-TLS 822 data messages may now be sent. This 823 message type MUST only be sent by the 824 PT-TLS session responder when the NEA 825 Client and NEA Server are in the PT- 826 TLS Negotiation phase. Recipients 827 MUST send an Invalid Message error 828 code in a PT-TLS Error message if a 829 Client Auth Success is received after 830 the PT-TLS Negotiation phase. 832 8 (PB-TNC Batch) Contains a PB-TNC batch. For more 833 information on PB-TNC batches see 834 section 4 of the PB-TNC specification. 835 This message type MUST only be sent 836 when the NEA Client and NEA Server are 837 in the PT-TLS Data Transport phase. 839 Recipients SHOULD send an Invalid 840 Message error code in a PT-TLS Error 841 message if a PB-TNC Batch is received 842 outside of the Data Transport phase. 844 9 (PT-TLS Error) PT-TLS Error message as described in 845 section 3.9. This message type may be 846 used during any PT-TLS phase. 848 10+ (Reserved) These values are reserved for future 849 allocation following guidelines 850 defined in the IANA Considerations 851 section 6.1. Recipients of messages 852 of type 13 or higher that do not 853 support the PT-TLS Message Type Vendor 854 ID and PT-TLS Message Type of a 855 received PT-TLS message MUST respond 856 with a Type Not Supported PT-TLS error 857 code in a PT-TLS Error message. 859 3.7. PT-TLS Version Negotiation 861 This section describes the message format and semantics for the PT- 862 TLS protocol version negotiation. This exchange is used by the PT- 863 TLS Session Initiator to trigger a version negotiation at the start 864 of an assessment. The PT-TLS session initiator MUST send a Version 865 Request message as its first PT-TLS message and MUST NOT send any 866 other PT-TLS messages on this connection until it receives a Version 867 Response message or an Error message. The PT-TLS session responder 868 MUST complete the version negotiation (or cause an error) prior to 869 sending or accepting reception of any additional messages. After the 870 successful completion of the version negotiation, both the Posture 871 Transport Client and Posture Transport Server MUST only send messages 872 compliant with the negotiated protocol version. Subsequent 873 assessments on the same session MUST use the negotiated version 874 number and therefore SHOULD NOT send additional version negotiation 875 messages. 877 3.7.1. Version Request Message 879 This message is sent by a PT-TLS Session Initiator as the first PT- 880 TLS message in a PT-TLS session. This message discloses the sender's 881 supported versions of the PT-TLS protocol. To ensure compatibility, 882 this message MUST always be sent using version 1 of the PT-TLS 883 protocol. Recipients of this message MUST respond with a Version 884 Response, or a PT-TLS Error message (Version Not Supported or Invalid 885 Message). The following diagram shows the format of the Version 886 Request Message: 888 1 2 3 889 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 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | Reserved | Min Vers | Max Vers | Pref Vers | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 Reserved 896 Reserved for future use. This field MUST be set to 0 on 897 transmission and ignored upon reception. 899 Min Vers 901 This field contains the minimum version of the PT-TLS 902 protocol supported by the sender. This field MUST be set to 903 1 indicating support for the first version of PT-TLS. 904 However, future versions of this specification will probably 905 remove this requirement so PT-TLS Session Responders MUST be 906 prepared to receive other values. 908 Max Vers 910 This field contains the maximum version of the PT-TLS 911 protocol supported by the sender. This field MUST be set to 912 1 indicating support for the first version of PT-TLS. 913 However, future versions of this specification will probably 914 remove this requirement so PT-TLS Session Responders MUST be 915 prepared to receive other values. 917 Pref Vers 919 This field contains the sender's preferred version of the 920 PT-TLS protocol. This is a hint to the recipient that the 921 sender would like this version selected if supported. The 922 value of this field MUST fall within the range of Min Vers 923 to Max Vers. This field MUST be set to 1 indicating support 924 for the first version of PT-TLS. However, future versions 925 of this specification will probably remove this requirement 926 so PT-TLS Session Responders MUST be prepared to receive 927 other values. 929 3.7.2. Version Response Message 931 This message is sent in response to receiving a Version Request 932 Message at the start of a new assessment session. If a recipient 933 receives a Version Request after a successful version negotiation has 934 occurred on the session, the recipient SHOULD send an Invalid Message 935 error code in a PT-TLS Error message and have TLS close the session. 936 This message MUST be sent using the syntax, semantics, and 937 requirements of the protocol version specified in this message. 939 1 2 3 940 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 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Reserved | Version | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 Reserved 947 Reserved for future use. This field MUST be set to 0 on 948 transmission and ignored upon reception. 950 Version 952 This field contains the version selected by the sender of 953 this message. The version selected MUST be within the Min 954 Vers to Max Vers inclusive range sent in the Version Request 955 Message. If a PT-TLS Session Initiator receives a message 956 with an invalid Version selected, the PT-TLS Session 957 Initiator MUST respond with a Version Not Supported PT-TLS 958 error message. 960 3.8. Client Authentication Message Exchange 962 This section includes a description of the message format and 963 contents necessary to perform client authentication 964 (authentication of the PT-TLS Session Initiator) over PT-TLS. 965 The general model used for providing a client side 966 authentication using PT-TLS messages over TLS is to have a 967 simple authentication exchange roughly equivalent to basic 968 authentication for HTTP [RFC2617] while also allowing for 969 extensibility so stronger methods can be added in the future. 971 Implementations compliant with the PT-TLS specification MUST 972 implement the Basic authentication type described in this 973 section. Future specifications are expected to include 974 additional types of authentication. For example, it is 975 expected that a widely used extensible authentication 976 technology such as EAP [RFC3748] will be included in the 977 future. 979 Because either the NEA Client or NEA Server can initiate the 980 TLS session used for the assessment, either could act as the 981 TLS server and be authenticated as part of the TLS exchange. 982 Therefore, either the NEA Client or NEA Server could also be 983 the party not authenticated during the TLS handshake (assuming 984 that TLS mutual authentication is not used) and be required to 985 authenticate using the PT-TLS client authentication. Typically 986 the NEA Client would setup the PT-TLS session (see section 3.1. 987 ), so the NEA Server would be triggering the client 988 authentication message exchanges and the NEA Client would be 989 the party being authenticated, thus the name "client 990 authentication". 992 If a client authentication is required, the TLS session 993 responder (typically the NEA Server) MUST initiate the client 994 authentication exchange by sending a Client Authentication 995 Request message or a Client Authentication Challenge message. 996 The Client Authentication Request message SHOULD be sent when 997 the TLS session responder is willing to authenticate the client 998 using multiple alternative authentication methods. The Client 999 Authentication Request message includes a prioritized list of 1000 the authentication methods that the TLS session responder 1001 (often the NEA Server) is willing to use and allows for the 1002 selection of one for use with this session. 1004 When a TLS session responder is only willing to accept the use 1005 of a single authentication method, the TLS session responder 1006 SHOULD optimistically start the authentication exchange by 1007 sending a Client Authentication Challenge in hopes that the 1008 other party is willing and able to use the supported type of 1009 authentication. If the PT-TLS Session Responder requires an 1010 authentication of the other party that was not performed during 1011 the TLS handshake and receives a PT-TLS Data Transport Phase 1012 message prior to client authentication successfully completing, 1013 the PT-TLS Session Responder SHOULD ignore the message and 1014 start the client authentication exchange (if it has not already 1015 done so). If a TLS Session Initiator receives a Client 1016 Authentication Challenge or Client Authentication Request as 1017 the next PT-TLS message after sending its first PT-TLS Data 1018 Transport Phase message, the initiator MUST assume that the TLS 1019 session responder requires an authentication prior to entering 1020 the PT-TLS Data Transport phase. 1022 Upon reception of a Client Authentication Request, the 1023 recipient MUST send a Client Authentication Selection message 1024 that selects a single authentication method from the list in 1025 the Client Authentication Request message or send an 1026 Authentication Error error code in a PT-TLS Error message. 1027 When the TLS session responder (e.g. NEA Server) receives the 1028 Client Authentication Selection message, it MUST respond with a 1029 Client Authentication Challenge message containing the 1030 challenge information relevant to the selected type of 1031 authentication. Some authentication schemes might not require 1032 an initial challenge from the server so the Client 1033 Authentication Challenge message might contain minimal 1034 information and largely serve to start the authentication 1035 exchange. After the successful selection of an authentication 1036 method, the Client Authentication Request and Client 1037 Authentication Selection messages MUST NOT be used again on the 1038 session. 1040 Now that an authentication method has been established, the 1041 client authentication involves a potentially multi-roundtrip 1042 message exchange until the PT-TLS Session Responder has 1043 confirmed the identity of the PT-TLS Session Initiator. The 1044 number of roundtrip messages and the contents of each message 1045 depend on the type of authentication selected. The client 1046 authentication messages are described in the following sub- 1047 sections. 1049 3.8.1. Client Authentication Request Message 1051 This message is sent when the TLS session responder (e.g. NEA Server) 1052 has decided that a client authentication is required. For example, 1053 this situation could occur following the initial establishment of the 1054 TLS session performing authentication only of the NEA Server when the 1055 NEA Server requires an authentication of the NEA Client. 1056 The following diagram shows the format of the Client Authentication 1057 Request message. Note that this message contains a list of Auth Type 1058 Vendor ID and associated Auth Type fields. The overall length of the 1059 PT-TLS message is used by the recipient to determine the number of 1060 authentication types offered in this message since each entry is 32 1061 bits in length. 1063 1 2 3 1064 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 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 | Auth Type Vendor ID | Auth Type | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | Auth Type Vendor ID | Auth Type | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 | . . . . . . | . . . . . | 1072 Auth Type Vendor ID 1074 This field indicates the owner of the name space associated 1075 with the following Auth Type field. Note that this field 1076 and the following Auth Type field will appear in pairs with 1077 one pair for every type of authentication being offered by 1078 the party requesting the authentication. 1080 This field is the 24 bit SMI Private Enterprise Number 1081 (Vendor ID) of the party who owns the Auth Type name space 1082 for the subsequent field. The IETF standard Auth Type 1083 values defined in this specification MUST use the IETF SMI 1084 Private Enterprise Number value (0) in this field. 1086 Auth Type 1088 This field indicates a type of authentication that the PT- 1089 TLS Session Responder is willing to perform in order to 1090 authenticate the PT-TLS Session Initiator's identity. The 1091 ordering of the authentication types in the list SHOULD be 1092 in the order of preference of the sender with the most 1093 preferred type first. Client Authentication Request message 1094 recipients SHOULD process the list of authentication types 1095 in the order received and select the first type that is 1096 acceptable based on local policies. 1098 3.8.1.1. Auth Type Values 1100 This section defines the IETF standard PT-TLS Auth Types used to 1101 identify the method of client authentication being used within a PT- 1102 TLS session. 1104 Posture Transport Clients and Posture Transport Servers MUST NOT 1105 require support for particular vendor-specific PT-TLS Auth Types and 1106 MUST interoperate with other parties despite any differences in the 1107 set of vendor-specific PT-TLS Auth Types supported (although they MAY 1108 permit administrators to configure vendor defined authentication 1109 types to be used). 1111 When the PT-TLS Auth Type Vendor ID is set to zero (0), the PT-TLS 1112 Auth Type is an IETF Standard PT-TLS authentication method. IANA 1113 maintains a registry of the IETF standard and vendor-specific PT-TLS 1114 Auth Types. Entries in this registry are added by Expert Review with 1115 Specification Required, following the guidelines in section 6.1. 1117 The following table summarizes the Auth Type values used when the 1118 Auth Type Vendor ID is set to the IETF SMI PEN (0). 1120 Value (Name) Definition 1121 ------------ ---------- 1122 0 (Experimental) Reserved for experimental use. This 1123 type will not offer interoperability 1124 but allows for experimentation. This 1125 value MUST be used only on a 1126 restricted, experimental network. 1127 Production code MUST NOT send an 1128 Experimental Auth Type and MUST send 1129 an Invalid Message error code in a PT- 1130 TLS Error message if an Experimental 1131 Auth Type is received. 1133 1 (Basic Auth) Indicates that the Authentication 1134 Information field contains a username 1135 and password as described in section 1136 3.8.4.1. 1138 3.8.2. Client Authentication Selection Message 1140 This message is sent by the PT-TLS Session Initiator in response to 1141 reception of a Client Authentication Request message. This message 1142 indicates the TLS session initiator's (typically the NEA Client's) 1143 selection of an authentication method offered in the Client 1144 Authentication Request message. The values in this message (Auth 1145 Type Vendor ID and Auth Type) must match one of the options listed in 1146 the preceding Client Authentication Request message. During the 1147 establishment of the TLS session, the TLS session initiator (e.g. NEA 1148 Client) MAY authenticate using a TLS defined client authentication 1149 method such as using client side X.509 certificates. If the TLS 1150 client authentication did not occur and is required by the TLS 1151 session responder, then it SHOULD request the authentication using 1152 the PT-TLS Client Authentication Request message. 1154 The following message shows the format of the Client Authentication 1155 Selection message: 1157 1 2 3 1158 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 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 | Auth Type Vendor ID | Auth Type | 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 Auth Type Vendor ID 1165 This field indicates the owner of the name space associated 1166 with the following Auth Type field that was selected. The 1167 name space owner information is expressed as the 24 bit SMI 1168 Private Enterprise Number (Vendor ID) of the party who owns 1169 the Auth Type name space for the subsequent Auth Type field. 1170 IETF standard values defined in this specification MUST use 1171 the IETF SMI Private Enterprise Number value of zero (0) in 1172 this field. 1174 Auth Type 1176 This field indicates a type of authentication that was 1177 selected from the list in the Client Authentication Request 1178 message received. The PT-TLS Session Initiator MUST select 1179 one authentication type (Auth Type Vendor ID and Auth Type) 1180 from the list sent in the Client Authentication Request 1181 message or send an Authentication error code in a PT-TLS 1182 Error message. The authentication type selection process 1183 SHOULD process the list in order and select the first type 1184 that is acceptable based upon its policies. 1186 3.8.3. Client Authentication Challenge Message 1188 This message is sent by the PT-TLS Session Responder (typically by 1189 the NEA Server) to initiate the authentication of the PT-TLS Session 1190 Initiator. Based upon the type of authentication being performed, 1191 the contents of the Challenge Information field will vary. For the 1192 details of the Challenge Information field for the Basic 1193 Authentication type see section 3.8.4.1. 1195 The following message shows the format of the Client Authentication 1196 Challenge message: 1198 1 2 3 1199 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 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 | Auth Type Vendor ID | Auth Type | 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 | Challenge Information | 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 | . . . . . . . . . . . | 1207 Auth Type Vendor ID 1209 This field indicates the owner of the name space associated 1210 with the following Auth Type field that was selected. The 1211 name space owner information is expressed as the 24 bit SMI 1212 Private Enterprise Number (Vendor ID) of the party who owns 1213 the Auth Type name space for the subsequent field. IETF 1214 standard values defined in this specification MUST use the 1215 IETF SMI Private Enterprise Number value of zero (0) in this 1216 field. 1218 Auth Type 1220 This field indicates the type of client authentication in 1221 use on the session. This field also indicates to the 1222 recipient the contents of the Challenge Information field 1223 (whose information varies based on authentication type and 1224 state). 1226 Challenge Information 1228 This field contains the authentication challenge in a format 1229 indicated by the type of authentication. The detailed 1230 format and semantics of this field for authentication types 1231 specified in this document are found in the following 1232 subsections. 1234 3.8.3.1. Basic Authentication Challenge 1236 This type of authentication is modeled on HTTP basic authentication. 1237 This authentication involves the client sending a username and 1238 password (or passphrase) to the server for authentication. Note that 1239 the password will travel over the PT-TLS session without special 1240 protection but it is afforded the full protections of TLS, so passive 1241 attacks should be unable to steal these credentials. 1243 For the Basic Authentication type of authentication, the Challenge 1244 Information field is empty. Basic authentication does not allow for 1245 the server to send information that alters the authentication 1246 response. 1248 3.8.4. Client Authentication Response Message 1250 This message is sent by the PT-TLS Session Initiator to prove its 1251 identity to the PT-TLS Session Responder. The format and contents of 1252 the Authentication Information vary depending on the type of 1253 authentication being performed and the state of the authentication 1254 exchange (e.g. when multi-roundtrip authentication protocols are 1255 used). 1257 The following message shows the format of the Client Authentication 1258 Response message: 1260 1 2 3 1261 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 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | Auth Type Vendor ID | Auth Type | 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 | Authentication Information | 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 | . . . . . . . . . . . | 1269 Auth Type Vendor ID 1271 This field indicates the owner of the name space associated 1272 with the following Auth Type field that was selected. The 1273 name space owner information is expressed as the 24 bit SMI 1274 Private Enterprise Number (Vendor ID) of the party who owns 1275 the Auth Type name space for the subsequent field. IETF 1276 standard values defined in this specification MUST use the 1277 IETF SMI Private Enterprise Number value of zero (0) in this 1278 field. 1280 Auth Type 1282 This field indicates the type of client authentication in 1283 use on the session. This field also indicates to the 1284 recipient the contents of the Challenge Information field 1285 (whose information varies based on authentication type and 1286 state). 1288 Authentication Information 1289 This field contains the authentication information in a 1290 format indicated by the type of authentication. The 1291 detailed format and semantics of this field for 1292 authentication types specified in this document are found in 1293 the following subsections. 1295 3.8.4.1. Basic Authentication Information 1297 This type of authentication is modeled on the HTTP basic 1298 authentication. This authentication involves the party being 1299 authenticated (the PT-TLS Session Initiator) sending a username and 1300 password (or passphrase) as a credential for authentication. 1301 Typically, the Authentication Information field will include the 1302 username and password for the NEA Client. The format and semantics 1303 are as follows: 1305 1 2 3 1306 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 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 | Auth Type Vendor ID | Auth Type | 1309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1310 | Username Length | Username | 1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 | . . . . . . . . . . . . . | 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 | Password | 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 | . . . . . . . . . . . . . | 1318 Auth Type Vendor ID 1320 This field indicates the owner of the name space associated 1321 with the following Auth Type field that was selected. The 1322 name space owner information is expressed as the 24 bit SMI 1323 Private Enterprise Number (Vendor ID) of the party who owns 1324 the Auth Type name space for the subsequent field. IETF 1325 standard values defined in this specification MUST use the 1326 IETF SMI Private Enterprise Number value of zero (0) in this 1327 field. 1329 Auth Type 1331 This field indicates the type of authentication in use on 1332 the session. This field also indicates to the recipient the 1333 contents of the Challenge Information field (whose 1334 information varies based on authentication type and state). 1336 Username Length 1338 This unsigned integer field indicates the octet length of 1339 the subsequent Username field. The Username field is 1340 variable length and is followed by the Password field that 1341 is also variable length, so the recipient needs to be able 1342 to identify the end of the Username and the start of the 1343 password. 1345 Username 1347 This field contains a string containing the identity of the 1348 party being authenticated. The Username MUST be encoded as 1349 a UTF-8 [RFC3629] string. NUL termination MUST NOT be 1350 employed. 1352 Password 1354 This field contains a string containing the authenticator 1355 associated with the claimed identity in the Username field. 1356 For the Basic type of authentication, the Password field 1357 MUST include a UTF-8 encoded string. NUL termination MUST 1358 NOT be employed. 1360 3.8.5. Client Authentication Successful Message 1362 This message is sent by the PT-TLS Session Responder to indicate that 1363 it has successfully completed authentication of the claimed identity 1364 and the PT-TLS session will now enter the PT-TLS Data Transport 1365 Phase. This message does not contain a Message Value field since the 1366 Message Type carries the only needed semantic (authentication was 1367 successful). The Client Authentication Successful message MUST be 1368 sent by a PT-TLS Session Responder (typically the NEA Server) at the 1369 completion of a successful authentication to indicate that the PT-TLS 1370 Session Initiator may now start sending NEA assessment messages. 1372 3.9. Error Message 1374 This section describes the format and contents of the PT-TLS Error 1375 Message sent by the NEA Client or NEA Server when it detects a PT-TLS 1376 level protocol error. Each error message contains an error code 1377 indicating the error that occurred, followed by a copy of the message 1378 that caused the error. 1379 When a PT-TLS error is received, the recipient MUST NOT respond with 1380 a PT-TLS error because this could result in an infinite loop of error 1381 messages being sent. Instead, the recipient MAY log the error, 1382 modify its behavior to avoid future errors, ignore the error, 1383 terminate the assessment, or take other action as appropriate (as 1384 long as it is consistent with the requirements of this 1385 specification). 1387 The Message Value portion of a PT-TLS Error Message contains the 1388 following information: 1390 1 2 3 1391 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 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 | Reserved | Error Code Vendor ID | 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1395 | Error Code | 1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1397 | Copy of Original Message (Variable Length) | 1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1399 | . . . . . . . | 1401 Reserved 1403 Reserved for future use. This field MUST be set to 0 on 1404 transmission and ignored upon reception. 1406 Error Code Vendor ID 1408 This field contains the IANA assigned SMI Private Enterprise 1409 Number for the vendor whose Error Code name space is being 1410 used in the message. For IETF standard Error Code values 1411 this field MUST be set to zero (0). For other vendor- 1412 defined Error Code name spaces this field MUST be set to the 1413 SMI Private Enterprise Number of the vendor. 1415 Error Code 1417 This field contains the error code. This error code exists 1418 within the scope of Error Code Vendor ID in this message. 1419 Posture Transport Clients and Posture Transport Servers MUST 1420 NOT require support for particular vendor-specific PT-TLS 1421 Error Codes and MUST interoperate with other parties despite 1422 any differences in the set of vendor-specific PT-TLS Error 1423 Codes supported (although they MAY permit administrators to 1424 configure them to require support for specific PT-TLS error 1425 codes). 1427 When the Error Code Vendor ID is set to the IETF Private 1428 Enterprise Number, the following table lists the supported 1429 IETF standard numeric error codes: 1431 Value (Name) Definition 1432 ------------ ---------- 1433 0 (Reserved) Reserved value indicates that the PT- 1434 TLS Error Message SHOULD be ignored by 1435 all recipients. This MAY be used for 1436 debugging purposes to allow a sender 1437 to see a copy of the message that was 1438 received while a receiver is operating 1439 on its contents. 1441 1 (Malformed Message) PT-TLS message unrecognized or 1442 unsupported. This error code SHOULD 1443 be sent when the basic message content 1444 sanity test fails. The sender of this 1445 error code MUST consider it a fatal 1446 error and abort the assessment. 1448 2 (Version Not Supported) This error SHOULD be sent when a PT- 1449 TLS session responder receives a PT- 1450 TLS Version Request message containing 1451 a range of version numbers that 1452 doesn't include any version numbers 1453 that the recipient is willing and able 1454 to support on the session. All PT-TLS 1455 messages carrying the Version Not 1456 Supported error code MUST use a 1457 Version number of 1. All parties that 1458 receive or send PT-TLS messages MUST 1459 be able to properly process an error 1460 message that meets this description, 1461 even if they cannot process any other 1462 aspect of PT-TLS version 1. The 1463 sender and receiver of this error code 1464 MUST consider this a fatal error and 1465 close the TLS session after sending or 1466 receiving this PT-TLS message. 1468 3 (Type Not Supported) PT-TLS message type unknown or not 1469 supported. When a recipient receives 1470 a PT-TLS message type that it does not 1471 support, it MUST send back this error, 1472 ignore the message and proceed. For 1473 example, this could occur if the 1474 sender used a Vendor ID for the 1475 Message Type that is not supported by 1476 the recipient. This error message 1477 does not indicate a fatal error has 1478 occurred, so the assessment is allowed 1479 to continue. 1481 4 (Failed Authentication) The authentication of the identity of 1482 the client failed. This could occur 1483 if the sent Username and Password (for 1484 the Basic authentication type) did not 1485 match those expected by the 1486 authenticating party. This error 1487 message does not indicate a fatal 1488 error has occurred, so the 1489 authentication is allowed to be re- 1490 started. 1492 5 (Invalid Message) PT-TLS message received was invalid 1493 based on the protocol state. For 1494 example, this error would be sent if a 1495 recipient receives a message 1496 associated with the PT-TLS Negotiation 1497 Phase (such as Version messages) after 1498 the protocol has reached the PT-TLS 1499 Data Transport Phase. The sender and 1500 receiver of this error code MUST 1501 consider it a fatal error and close 1502 the TLS session after sending or 1503 receiving this PT-TLS message. 1505 6 (Authentication Error) A fatal error occurred while trying to 1506 perform the client authentication. 1507 For example, the NEA Client is unable 1508 to support any of the offered types of 1509 authentication. The sender and 1510 receiver of this error code MUST 1511 consider it a fatal error and close 1512 the TLS session after sending or 1513 receiving this PT-TLS message. 1515 Copy of Original Message 1517 This variable length value contains a copy (up to 1024 1518 bytes) of the original PT-TLS message that caused the error. 1520 If the original message is longer than 1024 bytes, only the 1521 initial 1024 bytes will be included in this field. This 1522 field is included so the error recipient can determine which 1523 message sent caused the error. In particular, the recipient 1524 can use the Message Identifier field from the Copy of 1525 Original Message to determine which message caused the 1526 error. 1528 4. Security Considerations 1530 This section discusses the major threats potentially faced by each 1531 binding of the PT protocol and countermeasures provided by the PT-TLS 1532 protocol. 1534 4.1. Trust Relationships 1536 In order to understand where security countermeasures are necessary, 1537 this section starts with a discussion of where the NEA architecture 1538 envisions some trust relationships between the processing elements of 1539 the PT-TLS protocol. The following sub-sections discuss the trust 1540 properties associated with each portion of the NEA reference model 1541 directly involved with the processing of the PT-TLS protocol. 1543 4.1.1. Posture Transport Client 1545 The Posture Transport Client is trusted by the Posture Broker Client 1546 to: 1548 o Not observe, fabricate or alter the contents of the PB-TNC batches 1549 received from the network 1551 o Not observe, fabricate or alter the PB-TNC batches passed down 1552 from the Posture Broker Client for transmission on the network 1554 o Transmit on the network any PB-TNC batches passed down from the 1555 Posture Broker Client 1557 o Deliver properly security protected messages received from the 1558 network that are destined for the Posture Broker Client 1560 o Provide configured security protections (e.g. authentication, 1561 integrity and confidentiality) for the Posture Broker Client's PB- 1562 TNC batches sent on the network 1564 o Expose the authenticated identity of the Posture Transport Server 1565 o Verify the security protections placed upon messages received from 1566 the network to ensure the messages are authentic and protected 1567 from attacks on the network 1569 o Provide a secure, reliable, in order delivery, full duplex 1570 transport for the Posture Broker Client's messages 1572 The Posture Transport Client is trusted by the Posture Transport 1573 Server to: 1575 o Not send malicious traffic intending to harm (e.g. denial of 1576 service) the Posture Transport Server 1578 o Not send malformed messages (e.g. messages lacking PT-TLS header) 1580 o Not send invalid or incorrect responses to messages (e.g. errors 1581 when no error is warranted) 1583 o Not ignore or drop messages causing issues for the protocol 1584 processing (e.g. dropping PT-TLS Client Authentication Challenge 1585 messages) 1587 o Verify the security protections placed upon messages received from 1588 the network to ensure the messages are authentic and protected 1589 from attacks on the network 1591 4.1.2. Posture Transport Server 1593 The Posture Transport Server is trusted by the Posture Broker Server 1594 to: 1596 o Not observe, fabricate or alter the contents of the PB-TNC batches 1597 received from the network 1599 o Not observe, fabricate or alter the PB-TNC batches passed down 1600 from the Posture Broker Server for transmission on the network 1602 o Transmit on the network any PB-TNC batches passed down from the 1603 Posture Broker Server 1605 o Deliver properly security protected messages received from the 1606 network that are destined for the Posture Broker Server 1608 o Provide configured security protections (e.g. authentication, 1609 integrity and confidentiality) for the Posture Broker Server's 1610 messages sent on the network 1612 o Expose the authenticated identity of the Posture Transport Client 1614 o Verify the security protections placed upon messages received from 1615 the network to ensure the messages are authentic and protected 1616 from attacks on the network 1618 o Provide a secure, reliable, in order delivery, full duplex 1619 transport for the Posture Broker Server's messages 1621 The Posture Transport Server is trusted by the Posture Transport 1622 Client to: 1624 o Not send malicious traffic intending to harm (e.g. denial of 1625 service) the Posture Transport Server 1627 o Not send malformed messages (e.g. messages lacking PT-TLS header) 1629 o Not send invalid or incorrect responses to messages (e.g. errors 1630 when no error is warranted) 1632 o Not ignore or drop messages causing issues for the protocol 1633 processing (e.g. dropping PT-TLS Client Authentication Successful 1634 messages) 1636 o Verify the security protections placed upon messages received from 1637 the network to ensure the messages are authentic and protected 1638 from attacks on the network 1640 4.2. Security Threats and Countermeasures 1642 Beyond the trusted relationships assumed in section 4.1. the PT-TLS 1643 protocol faces a number of potential security attacks that could 1644 require security countermeasures. 1646 Generally, the PT-TLS protocol is responsible for offering strong 1647 security protections for all of the NEA protocols so any threats to 1648 its ability to protect NEA protocol messages could be very damaging 1649 to deployments. Once the message is delivered to the Posture Broker 1650 Client or Posture Broker Server, the posture brokers are trusted to 1651 properly and safely process the messages. 1653 4.2.1. Message Theft 1655 When PT-TLS messages are sent over unprotected network links or 1656 spanning local software stacks that are not trusted, the contents of 1657 the messages may be subject to information theft by an intermediary 1658 party. This theft could result in information being recorded for 1659 future use or analysis by the adversary. Messages observed by 1660 eavesdroppers could contain information that exposes potential 1661 weaknesses in the security of the endpoint, or system fingerprinting 1662 information easing the ability of the attacker to employ attacks more 1663 likely to be successful against the endpoint. The eavesdropper might 1664 also learn information about the endpoint or network policies that 1665 either singularly or collectively is considered sensitive 1666 information. For example, if PT-TLS does not provide confidentiality 1667 protection, an adversary could observe the PA-TNC attributes included 1668 in the PT-TLS message and determine that the endpoint is lacking 1669 patches, or particular sub-networks have more lenient policies. 1671 In order to protect against NEA assessment message theft, the PT-TLS 1672 protocol provides strong cryptographic authentication, integrity and 1673 confidentiality protection. Deployers are strongly encouraged to 1674 employ best practice of the day TLS ciphers to ensure the information 1675 remains safe despite advances in technology and discovered cipher 1676 weaknesses. The use of bi-directional authentication of the 1677 assessment transport session ensures that only properly authenticated 1678 and authorized parties may be involved in an assessment dialog. The 1679 PT-TLS protocol also provides strong cryptography for all of the PB- 1680 TNC and PA-TNC protocol messages traveling over the network allowing 1681 the message contents to be hidden from potential theft by the 1682 adversary even if the attacker is able to observe the encrypted PT- 1683 TLS session. 1685 4.2.2. Message Fabrication 1687 Attackers on the network or present within the NEA system could 1688 introduce fabricated PT-TLS messages intending to trick or create a 1689 denial of service against aspects of an assessment. For example, an 1690 adversary could attempt to insert into the message exchange fake PT- 1691 TLS error codes in order to disrupt communications. 1693 The PT-TLS protocol provides strong security protections for the 1694 complete message exchange over the network. These security 1695 protections prevent an intermediary from being able to insert fake 1696 messages into the assessment. In particular, the TLS's protocol use 1697 of hashing algorithms provides strong integrity protections that 1698 allow for detection of any changes in the content of the message 1699 stream. Additionally, adversaries are unable to observe the PT-TLS 1700 protocol exchanges because they are encrypted by the TLS ciphers, so 1701 would have difficulty in determining where to insert the falsified 1702 message, since the attacker is unable to determine where the message 1703 boundaries exist. Even a successful message insertion did occur; the 1704 recipient would be able to detect it due to the TLS cipher suite's 1705 integrity checking failing. 1707 4.2.3. Message Modification 1709 This attack could allow an active attacker capable of intercepting a 1710 message to modify a PT-TLS message or transported PA-TNC attribute to 1711 a desired value to ease the compromise of an endpoint. Without the 1712 ability for message recipients to detect whether a received message 1713 contains the same content as what was originally sent, active 1714 attackers can stealthily modify the attribute exchange. 1716 The PT-TLS protocol leverages the TLS protocol to provide strong 1717 authentication and integrity protections as a countermeasure to this 1718 theat. The bi-directional authentication prevents the attacker from 1719 acting as an active man-in-the-middle to the protocol that could be 1720 used to modify the message exchange. The strong integrity 1721 protections (e.g. hashing) offered by TLS allows PT-TLS message 1722 recipients to detect message alterations by other types of network 1723 based adversaries. 1725 4.2.4. Denial of Service 1727 A variety of types of denial of service attacks are possible against 1728 the PT-TLS protocol if the message exchanges are left unprotected 1729 while traveling over the network. The Posture Transport Client and 1730 Posture Transport Server are trusted not to participate in the denial 1731 of service of the assessment session, leaving the threats to come 1732 from the network. 1734 The PT-TLS protocol provides bi-directional authentication 1735 capabilities in order to prevent a man-in-the-middle on the network 1736 from becoming an undetected active proxy of PT-TLS messages. Because 1737 the PT-TLS protocol runs after the TLS handshake and thus cipher 1738 establishment/use, all of the PT-TLC messages are protected from 1739 undetected modification that could create a denial of service 1740 situation. However it is possible for an adversary to alter the 1741 message flows causing each message to be rejected by the recipient 1742 because it fails the integrity checking. 1744 The PT-TLS protocol operates as an application protocol on top of TLS 1745 and thus TCP/IP protocols, so is subject to denial of service attacks 1746 against the TLS, TCP and IP protocols. 1748 4.2.5. NEA Asokan Attacks 1750 As described in section 3.3. and in the NEA Asokan Attack Analysis 1751 [ASOKAN], a sophisticated MITM attack can be mounted against NEA 1752 systems. The attacker forwards PA-TNC messages from a healthy 1753 machine through an unhealthy one so that the unhealthy machine can 1754 gain network access. Section 3.3. and the NEA Asokan Attack Analysis 1755 provide a detailed description of this attack and of the 1756 countermeasures that can be employed against it. 1758 Because lying endpoint attacks are much easier than Asokan attacks 1759 and the only known effective countermeasure against lying endpoint 1760 attacks is the use of an External Measurement Agent (EMA), 1761 countermeasures against an Asokan attack are not necessary unless an 1762 EMA is in use. However, PT-TLS implementers may not know whether an 1763 EMA will be used with their implementation. Therefore, PT-TLS 1764 implementers SHOULD support the Asokan attack countermeasures by 1765 providing the value of the tls-unique channel binding to higher 1766 layers in the NEA reference model: Posture Broker Clients, Posture 1767 Broker Servers, Posture Collectors, and Posture Validators. 1769 5. Privacy Considerations 1771 The role of PT-TLS is to act as a secure transport for PB-TNC and 1772 other higher layer protocols. As such, PT-TLS does not directly 1773 utilize personally identifiable information (PII) except when client 1774 authentication is enabled. When client authentication is being used, 1775 the NEA Client will be asked to disclose a local identifier (e.g. 1776 username) associated with the endpoint and an authenticator (e.g. 1777 password) to authenticate that identity. Because the identity and 1778 authenticator are potentially privacy sensitive information, the NEA 1779 Client MUST offer a mechanism to restrict which NEA Servers will be 1780 sent this information. Similarly, the NEA Client should provide an 1781 indication to the person being identified that a request for their 1782 identity has been made in case they choose to opt out of the 1783 authentication to remain anonymous. 1785 PT-TLS provides cryptographic peer authentication, message integrity 1786 and data confidentiality protections to higher layer NEA protocols 1787 that may exchange data potentially including PII. These security 1788 services can be used to protect any PII involved in an assessment 1789 from passive and active attackers on the network. Endpoints sending 1790 potentially privacy sensitive information should ensure that the PT- 1791 TLS security protections (TLS cipher suites) negotiated for an 1792 assessment of the endpoint are adequate to avoid interception and 1793 off-line attacks of any long term privacy sensitive information. 1795 6. IANA Considerations 1797 This section defines the contents of three new IANA registries: 1798 PT-TLS Message Types, PT-TLS Auth Types, and PT-TLS Error 1799 Codes. This section explains how these registries work. 1801 All of the registries defined in this document support IETF 1802 standard values and vendor-defined values. To explain this 1803 phenomenon, we will use the PT-TLS Message Type as an example 1804 but the other registries work the same way. 1806 Whenever a PT-TLS Message Type appears on a network, it is 1807 always accompanied by an SMI Private Enterprise Number (PEN), 1808 also known as a vendor ID. If this vendor ID is zero, the 1809 accompanying PT-TLS Message Type is an IETF standard value 1810 listed in the IANA registry for PT-TLS Message Types and its 1811 meaning is defined in the specification listed for that PT-TLS 1812 Message Type in that registry. If the vendor ID is not zero, 1813 the meaning of the PT-TLS Message Type is defined by the vendor 1814 identified by the vendor ID (as listed in the IANA registry for 1815 SMI PENs). The identified vendor is encouraged but not required 1816 to register with IANA some or all of the PT-TLS Message Types 1817 used with their vendor ID and publish a specification for each 1818 of these values. 1820 This delegation of namespace is analogous to the technique used 1821 for OIDs. It can result in interoperability problems if 1822 vendors require support for particular vendor-specific values. 1823 However, such behavior is explicitly prohibited by this 1824 specification, which dictates that "Posture Transport Clients 1825 and Posture Transport Servers MUST NOT require support for 1826 particular vendor-specific PT-TLS Error Codes and MUST 1827 interoperate with other parties despite any differences in the 1828 set of vendor-specific PT-TLS Error Codes supported (although 1829 they MAY permit administrators to configure them to require 1830 support for specific PT-TLS error codes)." Similar requirements 1831 are included for PT-TLS Message Types and PT-TLS Auth Types. 1833 6.1. Designated Expert Guidelines 1835 For all of the IANA registries defined by this specification, 1836 new values are added to the registry by Expert Review with 1837 Specification Required, using the Designated Expert process 1838 defined in RFC 5226 [RFC5226]. 1840 This section provides guidance to designated experts so that 1841 they may make decisions using a philosophy appropriate for 1842 these registries. 1844 The registries defined in this document have plenty of values. 1845 In most cases, the IETF has approximately 2^32 values available 1846 for it to define and each vendor has the same number of values 1847 for its use. Because there are so many values available, 1848 designated experts should not be terribly concerned about 1849 exhausting the set of values. 1851 Instead, designated experts should focus on the following 1852 requirements. All values in these IANA registries MUST be 1853 documented in a specification that is permanently and publicly 1854 available. IETF standard values MUST also be useful, not 1855 harmful to the Internet, and defined in a manner that is clear 1856 and likely to ensure interoperability. 1858 Designated experts should encourage vendors to avoid defining 1859 similar but incompatible values and instead agree on a single 1860 IETF standard value. However, it is beneficial to document 1861 existing practice. 1863 There are several ways to ensure that a specification is 1864 permanently and publicly available. It may be published as an 1865 RFC. Alternatively, it may be published in another manner that 1866 makes it freely available to anyone. However, in this latter 1867 case, the vendor MUST supply a copy to the IANA and authorize 1868 the IANA to archive this copy and make it freely available to 1869 all if at some point the document becomes no longer freely 1870 available to all through other channels. 1872 The following three sections provide guidance to the IANA in 1873 creating and managing the new IANA registries defined by this 1874 specification. 1876 6.2. Registry for PT-TLS Message Types 1878 The name for this registry is "PT-TLS Message Types". Each 1879 entry in this registry should include a human-readable name, an 1880 SMI Private Enterprise Number, a decimal integer value between 1881 0 and 2^32-1, and a reference to the specification where the 1882 contents of this message type are defined. This specification 1883 must define the meaning of the PT-TLS message type and the 1884 format and semantics of the PT-TLS Message Value field that 1885 include the designated Private Enterprise Number in the PT-TLS 1886 Message Type Vendor ID field and the designated numeric value 1887 in the PT-TLS Message Type field. 1889 The following entries for this registry are defined in this 1890 document. Once this document becomes an RFC, they should 1891 become the initial entries in the registry for PT-TLS Message 1892 Types. Additional entries to this registry are added by Expert 1893 Review with Specification Required, following the guidelines in 1894 section 6.1. 1896 PEN Value Name Defining Specification 1897 --- ----- ---- ---------------------- 1898 0 0 Experimental RFC # Assigned to this I-D 1899 0 1 Version Request RFC # Assigned to this I-D 1900 0 2 Version Response RFC # Assigned to this I-D 1901 0 3 Client Auth Request RFC # Assigned to this I-D 1902 0 4 Client Auth Selection RFC # Assigned to this I-D 1903 0 5 Client Auth Challenge RFC # Assigned to this I-D 1904 0 6 Client Auth Response RFC # Assigned to this I-D 1905 0 7 Client Auth Success RFC # Assigned to this I-D 1906 0 8 PT-TLS Batch RFC # Assigned to this I-D 1907 0 9 Reserved RFC # Assigned to this I-D 1908 0 10 Reserved RFC # Assigned to this I-D 1909 0 11 PT-TLS Error RFC # Assigned to this I-D 1910 0 12 Reserved RFC # Assigned to this I-D 1911 0 0xffffffff Reserved RFC # Assigned to this I-D 1913 6.3. Registry for PT-TLS Error Codes 1915 The name for this registry is "PT-TLS Error Codes". Each entry 1916 in this registry should include a human-readable name, an SMI 1917 Private Enterprise Number, a decimal integer value between 0 1918 and 2^32-1, and a reference to the specification where this 1919 error code is defined. This specification must define the 1920 meaning of this error code and the format and semantics of the 1921 Error Information field for PT-TLS messages that have a PT-TLS 1922 Vendor ID of 0, a PT-TLS Message Type of PT-TLS Error, the 1923 designated Private Enterprise Number in the PT-TLS Error Code 1924 Vendor ID field, and the designated numeric value in the PT-TLS 1925 Error Code field. 1927 The following entries for this registry are defined in this 1928 document. Once this document becomes an RFC, they should 1929 become the initial entries in the registry for PT-TLS Error 1930 Codes. Additional entries to this registry are added by Expert 1931 Review with Specification Required, following the guidelines in 1932 section 6.1. 1934 PEN Value Name Defining Specification 1935 --- ----- ---- ---------------------- 1936 0 0 Reserved RFC # Assigned to this I-D 1937 0 1 Malformed Message RFC # Assigned to this I-D 1938 0 2 Version Not Supported RFC # Assigned to this I-D 1939 0 3 Type Not Supported RFC # Assigned to this I-D 1940 0 4 Failed Authentication RFC # Assigned to this I-D 1941 0 5 Invalid Message Error RFC # Assigned to this I-D 1942 0 6 Authentication Error RFC # Assigned to this I-D 1944 6.4. Registry for PT-TLS Auth Types 1946 The name for this registry is "PT-TLS Auth Types". Each entry 1947 in this registry should include a human-readable name, an SMI 1948 Private Enterprise Number, a decimal integer value between 0 1949 and 255, and a reference to the specification where this 1950 authentication type is defined. This specification must define 1951 the defined authentication mechanism including the format and 1952 semantics of the Authentication Information and Challenge 1953 Information fields for PT-TLS client authentication message 1954 exchange described in section 3.8. 1956 The following entries for this registry are defined in this 1957 document. Once this document becomes an RFC, they should 1958 become the initial entries in the registry for PT-TLS Auth 1959 Types. Additional entries to this registry are added by Expert 1960 Review with Specification Required, following the guidelines in 1961 section 6.1. 1963 PEN Value Name Defining Specification 1964 --- ----- ---- ---------------------- 1965 0 0 Experimental RFC # Assigned to this I-D 1966 0 1 Basic Auth RFC # Assigned to this I-D 1968 7. Acknowledgments 1970 The author of this draft would also like to acknowledge the following 1971 people who have contributed to or provided substantial input on the 1972 preparation of this document or predecessors to it: Stuart Bailey, 1973 Lauren Giroux, Steve Hanna, Josh Howlett, Scott Kelly, Sung Lee, Lisa 1974 Lorenzin, Ravi Sahita, and Mark Townsend. 1976 This document was prepared using 2-Word-v2.0.template.dot. 1978 8. References 1980 8.1. Normative References 1982 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1983 Requirement Levels", BCP 14, RFC 2119, March 1997. 1985 [RFC2617] Franks, J., P. Hallam-Baker, J. Hostetler, S. Lawrence, P. 1986 Leach, A. Luotonen, and L. Stewart, "HTTP Authentication: 1987 Basic and Digest Access Authentication", RFC 2617, June 1988 1999. 1990 [RFC3629] Yergeau F., "UTF-8, a transformation format of ISO 10646", 1991 RFC 3629, November 2003. 1993 [RFC4346] Dierks T., Rescorla E., "The Transport Layer Security (TLS) 1994 Protocol Version 1.1", RFC 4346, April 2006. 1996 [RFC5226] Narten T., Alvestrand H., "Guidelines for Writing an IANA 1997 Considerations Section in RFCs", RFC 5226, May 2008. 1999 [RFC5246] Dierks T., Rescorla E., "The Transport Layer Security (TLS) 2000 Protocol Version 1.2", RFC 5246, August 2008. 2002 [RFC5792] Sangster P., Narayan K., "PA-TNC: A Posture Attribute 2003 Protocol (PA) Compatible with TNC", RFC 5792, March 2010. 2005 [RFC5793] Sahita, R., Hanna, S., and R. Hurst, "PB-TNC: A Posture 2006 Broker Protocol (PB) Compatible with TNC", RFC 5793, March 2007 2010. 2009 8.2. Informative References 2011 [ASOKAN] Salowey, J., Hanna, S., "NEA Asokan Attack Analysis", 2012 draft-salowey-nea-asokan-00.txt (work in progress), October 2013 2010. 2015 [IFT-TLS] Trusted Computing Group, "TNC IF-T: Binding to TLS", 2016 http://www.trustedcomputinggroup.org/files/resource_files/5 2017 1F0757E-1D09-3519- 2018 AD63B6FD099658A6/TNC_IFT_TLS_v1_0_r16.pdf, May 2009. 2020 [PT-EAP] Hanna, S., Sangster, P., "PT-EAP: Posture Transport (PT) 2021 Protocol For EAP Tunnel Methods", draft-hanna-nea-pt-eap- 2022 01.txt (work in progress), March 2011. 2024 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 2025 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 2026 3748, June 2004. 2028 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 2029 Tardo, "Network Endpoint Assessment (NEA): Overview and 2030 Requirements", RFC 5209, June 2008. 2032 [RFC5929] Altman, J., Williams, N., Zhu L., "Channel Bindings for 2033 TLS", RFC 5929, July 2010. 2035 Appendix A. Evaluation Against NEA Requirements 2037 This section evaluates the PT-TLS protocol against the PT 2038 requirements defined in the NEA Overview and Requirements and 2039 PB-TNC specifications. Each subsection considers a separate 2040 requirement and highlights how PT-TLS meets the requirement. 2042 A.1. Evaluation Against Requirement C-1 2044 Requirement C-1 says: 2046 C-1 NEA protocols MUST support multiple round trips between 2047 the NEA Client and NEA Server in a single assessment. 2049 PT-TLS meets this requirement. Use of the TLS protocol over 2050 TCP/IP allows for multiple round trips of PT-TLS messages, 2051 which can carry multiple round trips of PB-TNC batches. 2053 A.2. Evaluation Against Requirements C-2 2055 Requirement C-2 says: 2057 C-2 NEA protocols SHOULD provide a way for both the NEA 2058 Client and the NEA Server to initiate a posture assessment or 2059 reassessment as needed. 2061 PT-TLS meets this requirement. PT-TLS allows the NEA Client or 2062 the NEA Server to initiate a posture assessment or 2063 reassessment. 2065 A.3. Evaluation Against Requirements C-3 2067 Requirement C-3 says: 2069 C-3 NEA protocols including security capabilities MUST be 2070 capable of protecting against active and passive attacks by 2071 intermediaries and endpoints including prevention from replay 2072 based attacks. 2074 PT-TLS meets this requirement. The use of TLS provides strong 2075 cryptographic authentication, integrity and confidentiality 2076 services for the NEA protocols. 2078 A.4. Evaluation Against Requirements C-4 2080 Requirement C-4 says: 2082 C-4 The PA and PB protocols MUST be capable of operating over 2083 any PT protocol. For example, the PB protocol must provide a 2084 transport independent interface allowing the PA protocol to 2085 operate without change across a variety of network protocol 2086 environments (e.g. EAP/802.1X, PANA, TLS and IKE/IPsec). 2088 While this requirement is not applicable to PT, the PT-TLS 2089 protocol is independent of PA and PB allowing those protocols 2090 to operate over other PT protocols. 2092 A.5. Evaluation Against Requirements C-5 2094 Requirement C-5 says: 2096 C-5 The selection process for NEA protocols MUST evaluate and 2097 prefer the reuse of existing open standards that meet the 2098 requirements before defining new ones. The goal of NEA is not 2099 to create additional alternative protocols where acceptable 2100 solutions already exist. 2102 Based on this requirement, PT-TLS should receive a strong 2103 preference. PT-TLS is equivalent with IF-T Binding to TLS 1.0, 2104 an open TCG specification. Selecting PT-TLS as the basis for 2105 the PT protocol will ensure compatibility with IF-T Binding to 2106 TLS, and with its implementations. 2108 A.6. Evaluation Against Requirements C-6 2110 Requirement C-6 says: 2112 C-6 NEA protocols MUST be highly scalable; the protocols MUST 2113 support many Posture Collectors on a large number of NEA 2114 Clients to be assessed by numerous Posture Validators residing 2115 on multiple NEA Servers. 2117 PT-TLS meets this requirement. The PT-TLS protocol is 2118 independent of the quantity or size of the PA-TNC messages and 2119 the number of Posture Collectors and Posture Validators. PT- 2120 TLS provides the Posture Broker Client and Posture Broker 2121 Server a transport capable of carrying PT-TNC batches up to 2122 2^32-16 octets in length. Posture Broker Clients and Posture 2123 Broker Servers wishing to send a PB-TNC batch longer than 2^32- 2124 16 octets could opt to split up set of attributes into multiple 2125 PB-TNC batches and send them sequentially since PT-TLS is full 2126 duplex. 2128 The fields present in the PT-TLS protocol are also very 2129 scalable, allowing for the definition of a large (2^32) number 2130 of IETF standard and vendor-defined PT-TLS message types and 2131 message identifiers. 2133 A.7. Evaluation Against Requirements C-7 2135 Requirement C-7 says: 2137 C-7 The protocols MUST support efficient transport of a large 2138 number of attribute messages between the NEA Client and the NEA 2139 Server. 2141 PT-TLS meets this requirement. PT-TLS will allow for transport 2142 of a very large number of attributes leveraging the underlying 2143 TCP/IP network access. The PT-TLS protocol only adds 16 octets 2144 of overhead per PT-TLS message, which is negligible since a 2145 single PT-TLS message might carry very many PA-TNC attributes 2146 within a single PB-TNC batch. 2148 A.8. Evaluation Against Requirements C-8 2150 Requirement C-8 says: 2152 C-8 NEA protocols MUST operate efficiently over low bandwidth 2153 or high latency links. 2155 PT-TLS protocols meet this requirement. TLS will operate well 2156 over high latency or low bandwidth links leveraging TCP's 2157 ability to adjust to the underlying network carrier. The NEA 2158 protocols encapsulated by the PT-TLS protocol are designed to 2159 be able to operate over EAP with long RADIUS proxy chains so 2160 they can adapt to high latency or low bandwidth links. With the 2161 small amount of overhead added by PT-TLS, TLS, and TCP/IP, 2162 these protocols should still be efficient over high latency or 2163 low bandwidth networks. 2165 A.9. Evaluation Against Requirements C-9 2167 Requirement C-9 says: 2169 C-9 For any strings intended for display to a user, the 2170 protocols MUST support adapting these strings to the user's 2171 language preferences. 2173 PT-TLS meets this requirement. The PT-TLS protocol does not 2174 include messages intended for display to the user. 2176 A.10. Evaluation Against Requirements C-10 2178 Requirement C-10 says: 2180 C-10 NEA protocols MUST support encoding of strings in UTF-8 2181 format. 2183 PT-TLS meets this requirement. All strings in the PT-TLS 2184 protocol are encoded in UTF-8 format. This allows the protocol 2185 to support a wide range of languages efficiently. 2187 A.11. Evaluation Against Requirements C-11 2189 Requirement C-11 says: 2191 C-11 Due to the potentially different transport 2192 characteristics provided by the underlying candidate PT 2193 protocols, the NEA Client and NEA Server MUST be capable of 2194 becoming aware of and adapting to the limitations of the 2195 available PT protocol. For example, some PT protocol 2196 characteristics that might impact the operation of PA and PB 2197 include restrictions on: which end can initiate a NEA 2198 connection, maximum data size in a message or full assessment, 2199 upper bound on number of roundtrips, and ordering (duplex) of 2200 messages exchanged. The selection process for the PT protocols 2201 MUST consider the limitations the candidate PT protocol would 2202 impose upon the PA and PB protocols. 2204 PT-TLS meets this requirement. The PT-TLS protocol leverages 2205 the underlying TLS connection to offer a reliable, full duplex 2206 session capable of being initiated by the NEA Client or NEA 2207 Server. This TLS session allows for transmission of large PB- 2208 TNC batches with many roundtrips with very low overhead (only 2209 16 octets of protocol overhead per PT-TLS message). 2211 A.12. Evaluation Against Requirements PT-1 2213 Requirement PT-1 says: 2215 PT-1 The PT protocol MUST NOT interpret the contents of PB 2216 messages being transported, i.e., the data it is carrying must 2217 be opaque to it. 2219 PT-TLS meets this requirement. The PT-TLS protocol 2220 encapsulates PB-TNC batches without interpreting their 2221 contents. 2223 A.13. Evaluation Against Requirements PT-2 2225 Requirement PT-2 says: 2227 PT-2 The PT protocol MUST be capable of supporting mutual 2228 authentication, integrity, confidentiality, and replay 2229 protection of the PB messages between the Posture Transport 2230 Client and the Posture Transport Server. 2232 PT-TLS meets this requirement. The PT-TLS protocol leverages 2233 TLS to provide mutual authentication, integrity protection and 2234 confidentiality as well as replay protection. For more 2235 information see the Security Considerations section 4. 2237 A.14. Evaluation Against Requirements PT-3 2239 Requirement PT-3 says: 2241 PT-3 The PT protocol MUST provide reliable delivery for the PB 2242 protocol. This includes the ability to perform fragmentation 2243 and reassembly, detect duplicates, and reorder to provide in- 2244 sequence delivery, as required. 2246 PT-TLS meets this requirement. The PT-TLS protocol operates 2247 over TCP/IP which provides fragmentation/reassembly services 2248 and can detect/discard duplicate message and re-order messages 2249 if they arrive out of order over the network. PT-TLS provides 2250 a reliable, in-order delivery NEA message transport to the 2251 Posture Broker Client and Posture Broker Server components. 2253 A.15. Evaluation Against Requirements PT-4 2255 Requirement PT-4 says: 2257 PT-4 The PT protocol SHOULD be able to run over existing 2258 network access protocols such as 802.1X and IKEv2. 2260 PT-TLS does NOT meet this requirement as it's intended for a 2261 different usage. PT-TLS protocol requires the use of a TCP/IP 2262 connection to the network. PT-EAP (PT Binding to EAP Tunnel 2263 Methods) meets this requirement. PT-TLS is intended to be used 2264 after the endpoint has been admitted to the network. 2266 A.16. Evaluation Against Requirements PT-5 2268 Requirement PT-5 says: 2270 PT-5 The PT protocol SHOULD be able to run between a NEA Client 2271 and NEA Server over TCP or UDP (similar to Lightweight 2272 Directory Access Protocol (LDAP)). 2274 PT-TLS meets this requirement. The PT-TLS protocol operates on 2275 top of an existing TCP/IP connection using TLS for network 2276 security. 2278 A.17. Evaluation Against Requirements PT-6 (from PB-TNC specification) 2280 Requirement PT-6 says: 2282 PT-6 The PT protocol MUST be connection oriented; it MUST 2283 support confirmed initiation and close down. 2285 PT-TLS meets this requirement. The PT-TLS protocol operates on 2286 top of an existing TCP/IP connection which is connection 2287 oriented and supports confirmed initiation and tear down of the 2288 connection. 2290 A.18. Evaluation Against Requirements PT-7 (from PB-TNC specification) 2292 Requirement PT-7 says: 2294 PT-7 The PT protocol MUST be able to carry binary data. 2296 PT-TLS meets this requirement. The PT-TLS protocol is capable 2297 of carrying binary data. 2299 A.19. Evaluation Against Requirements PT-8 (from PB-TNC specification) 2301 Requirement PT-8 says: 2303 PT-8 The PT protocol MUST provide mechanisms for flow control 2304 and congestion control. 2306 PT-TLS meets this requirement. The PT-TLS protocol operates on 2307 top of TCP/IP which provides flow and congestion control. 2309 A.20. Evaluation Against Requirements PT-9 (from PB-TNC specification) 2311 Requirement PT-9 says: 2313 PT-9 PT protocol specifications MUST describe the capabilities 2314 that they provide for and limitations that they impose on the 2315 PB protocol (e.g. half/full duplex, maximum message size). 2317 PT-TLS meets this requirement. This specification discusses 2318 the level of transport service provided to the Posture Broker 2319 Client and Posture Broker Server. Generally, the PT-TLS 2320 protocol supports the post network admission usages discussed 2321 in RFC 5209. The maximum message size for PT-TLS is only 16 2322 octets less then the maximum message size allowable by PB-TNC. 2324 Authors' Addresses 2326 Paul Sangster 2327 Symantec Corporation 2328 6825 Citrine Dr 2329 Carlsbad, CA 92009 2331 Email: paul_sangster@symantec.com