idnits 2.17.1 draft-ietf-nea-pt-tls-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 25, 2012) is 4382 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 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) == Outdated reference: A later version (-02) exists of draft-ietf-nea-asokan-00 == Outdated reference: A later version (-09) exists of draft-ietf-nea-pt-eap-01 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 N. Cam-Winget 4 Expires: October 2012 J. Salowey 5 Cisco Systems 6 April 25, 2012 8 PT-TLS: A TCP-based Posture Transport (PT) Protocol 9 draft-ietf-nea-pt-tls-03.txt 11 Abstract 13 This document specifies PT-TLS, a TCP-based Posture Transport (PT) 14 protocol. The PT-TLS protocol carries the Network Endpoint 15 Assessment (NEA) message exchange under the protection of a Transport 16 Layer Security (TLS) secured tunnel. 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 October 25, 2012. 41 Copyright Notice 43 Copyright (c) 2012 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. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction...................................................3 59 1.1. Prerequisites.............................................4 60 1.2. Message Diagram Conventions...............................4 61 1.3. Conventions used in this document.........................4 62 1.4. Compatibility with other Specifications...................4 63 2. Design Considerations..........................................5 64 2.1. Benefits of TCP/IP Connectivity...........................5 65 2.2. Leveraging Proven TLS Security............................6 66 2.3. TLV-Oriented Based Message Encapsulation..................6 67 2.4. No Change to Base TLS Protocol............................6 68 3. PT-TLS Protocol................................................7 69 3.1. Initiating a PT-TLS Session...............................8 70 3.1.1. Issues with Server Initiated PT-TLS Sessions.........8 71 3.1.2. Establish or Re-Use Existing PT-TLS Session..........9 72 3.2. TCP Port Usage............................................9 73 3.3. Preventing MITM Attacks with Channel Bindings.............9 74 3.4. PT-TLS Message Flow......................................10 75 3.4.1. Assessment Triggers.................................10 76 3.4.2. PT-TLS Message Exchange Phases......................10 77 3.4.2.1. TLS Setup Phase................................11 78 3.4.2.2. PT-TLS Negotiation Phase.......................12 79 3.4.2.3. PT-TLS Data Transport Phase....................13 80 3.4.3. TLS Requirements....................................14 81 3.5. PT-TLS Message Format....................................14 82 3.6. IETF Standard PT-TLS Message Types.......................17 83 3.7. PT-TLS Version Negotiation...............................19 84 3.7.1. Version Request Message.............................20 85 3.7.2. Version Response Message............................21 86 3.8. Client Authentication using SASL.........................21 87 3.8.1. SASL Entity Authentication Requirements.............22 88 3.8.2. SASL in PT-TLS Overview.............................23 89 3.8.3. SASL Authentication Flow............................23 90 3.8.4. Aborting SASL Authentication........................24 91 3.8.5. Linkages to SASL Framework..........................24 92 3.8.5.1. SASL Service Name..............................24 93 3.8.5.2. SASL Authorization Identity....................24 94 3.8.5.3. SASL Security Layer............................24 95 3.8.5.4. Multiple Authentications.......................24 96 3.8.6. SASL Channel Bindings...............................24 97 3.8.7. SASL Mechanisms.....................................25 98 3.8.8. SASL Mechanism Selection............................25 99 3.8.9. SASL Authentication Data............................26 100 3.8.10. SASL Result........................................27 101 3.9. Error Message............................................28 102 4. Security Considerations.......................................31 103 4.1. Trust Relationships......................................32 104 4.1.1. Posture Transport Client............................32 105 4.1.2. Posture Transport Server............................33 106 4.2. Security Threats and Countermeasures.....................34 107 4.2.1. Message Theft.......................................34 108 4.2.2. Message Fabrication.................................35 109 4.2.3. Message Modification................................35 110 4.2.4. Denial of Service...................................36 111 4.2.5. NEA Asokan Attacks..................................36 112 4.2.6. Trust Anchors.......................................37 113 5. Privacy Considerations........................................37 114 6. IANA Considerations...........................................38 115 6.1. Designated Expert Guidelines.............................39 116 6.2. Registry for PT-TLS Message Types........................39 117 6.3. Registry for PT-TLS Error Codes..........................40 118 7. Acknowledgments...............................................41 119 8. References....................................................41 120 8.1. Normative References.....................................41 121 8.2. Informative References...................................42 123 1. Introduction 125 This document specifies PT-TLS, a TCP-based Posture Transport (PT) 126 protocol protected by a TLS channel. The document then evaluates PT- 127 TLS against the applicable requirements defined in the NEA Overview 128 and Requirements [RFC5209] and PB-TNC [RFC5793] specifications. 130 NEA protocols are intended to be used for pre-admission assessment of 131 endpoints joining the network and to assess endpoints already present 132 on the network. In order to support both usage models, two different 133 types (or bindings) of PT protocols are necessary to operate before 134 and after the endpoint has an assigned IP address and other network 135 layer information. This specification focuses on the PT protocol 136 used to assess endpoints already present on the network and thus is 137 able to use TCP/IP based transport protocols. NEA has defined 138 another protocol called PT-EAP [PT-EAP] to address assessment prior 139 to the endpoint having an assigned IP address. 141 The PT protocol in the NEA architecture is responsible for 142 transporting PB-TNC batches (often containing PA-TNC [RFC5792] 143 attributes) over the network between the Posture Transport Client 144 component of the NEA Client and the Posture Transport Server 145 component of the NEA Server. The PT protocol also offers strong 146 security protections to ensure the exchanged messages are protected 147 from a variety of threats from hostile intermediaries. 149 1.1. Prerequisites 151 This document does not define an architecture or reference model. 152 Instead, it defines one binding of the PT protocol that works within 153 the reference model described in the NEA Overview and Requirements 154 specification. The reader is assumed to be thoroughly familiar with 155 the NEA Overview and Requirements specification. 157 1.2. Message Diagram Conventions 159 This specification defines the syntax of PT-TLS messages using 160 diagrams. Each diagram depicts the format and size of each field in 161 bits. Implementations MUST send the bits in each diagram as they are 162 shown, traversing the diagram from top to bottom and then from left 163 to right within each line (which represents a 32-bit quantity). 164 Multi-byte fields representing numeric values must be sent in network 165 (big endian) byte order. 167 Descriptions of bit field (e.g. flag) values are described referring 168 to the position of the bit within the field. These bit positions are 169 numbered from the most significant bit through the least significant 170 bit so a one octet field with only bit 0 set has the value 0x80. 172 1.3. Conventions used in this document 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in RFC 2119 [RFC2119]. 178 1.4. Compatibility with other Specifications 180 One of the goals of the NEA effort is to deliver a single set of 181 endpoint assessment standards, agreed upon by all parties. For this 182 reason, the Trusted Computing Group (TCG) will be replacing its 183 existing posture transport protocols with new versions that are 184 equivalent to and interoperable with the NEA specifications. 186 2. Design Considerations 188 This section discusses some of the key design considerations for the 189 PT protocol. This document specifies the PT binding for use when 190 performing an assessment or reassessment after the endpoint has been 191 admitted to the network and is capable of using TCP/IP to communicate 192 with the NEA Server. If the endpoint does not yet have TCP/IP layer 193 access to the NEA Server (and vice versa), the endpoint should use 194 the PT-EAP (Posture Transport (PT) Protocol for EAP Tunnel Methods) 195 protocol when performing an assessment. 197 Because the endpoint has TCP/IP access to the NEA Server (potentially 198 on a restricted portion of the network), the NEA Client and NEA 199 Server have the ability to establish (or re-use) a reliable TCP/IP 200 connection in order to perform the assessment. The TCP/IP connection 201 enables the assessment to occur over a relatively high performance, 202 reliable channel capable of supporting multiple roundtrip message 203 exchanges in full duplex manner. These connection properties are 204 very different from what is available when the endpoint is initially 205 joining the network (e.g. during an 802.1X based assessment), 206 therefore the design described in this specification follows a 207 different path to maximize the benefits of the underlying TCP/IP 208 connection. 210 2.1. Benefits of TCP/IP Connectivity 212 The PT protocol is typically able to offer to the NEA Client and NEA 213 Server significantly higher quality of service and flexibility of 214 operation than PT-EAP (Posture Transport (PT) Protocol for EAP Tunnel 215 Methods). However, there may be some added risks when the endpoint 216 is on the network prior to its initial assessment (if no admission 217 time assessment had been performed). Because of these risks, the 218 combined use of an EAP-based assessment during admission followed by 219 reassessment using TCP/IP may be appropriate in some environments. 220 Some of the benefits to having a TCP/IP based transport during an 221 assessment include: 223 o Full Duplex connectivity - used to support asynchronous initiation 224 of posture exchanges within a single TLS connection (e.g. 225 triggered by alerts of posture or policy changes) 227 o High Bandwidth - potentially much higher bandwidth than other 228 transports (e.g. EAP) allowing more in-band data (e.g. 229 remediation, verbose posture information) 231 o Large Messages - ability to send very large PA messages without 232 directly fragmenting them (underlying carrier protocol may 233 introduce fragmentation) 235 o Bi-directional - NEA Client and NEA Server can initiate an 236 assessment or reassessment 238 o Multiple Roundtrips - NEA Client and NEA Server can exchange 239 numerous messages without fear of infrastructure timeouts. 240 However, the entire exchange should be kept as brief as possible 241 if the user has to wait for its completion. 243 2.2. Leveraging Proven TLS Security 245 All PT protocol bindings must be capable of providing strong 246 authentication, integrity and confidentiality protection for the PB- 247 TNC batches. Rather than define a new protocol over TCP/IP to 248 provide adequate protection, this specification requires the use of 249 Transport Layer Security [RFC5246] to secure the connection. TLS was 250 selected because it's a widely deployed protocol with parallel 251 protections to a number of the EAP tunnel methods, and it meets all 252 of the security requirements. 254 2.3. TLV-Oriented Based Message Encapsulation 256 The design of the PT-TLS protocol is based upon the use of type- 257 length-value (TLV) oriented protocol message that identifies the type 258 of message, the message's length and a potentially variable length 259 payload value. The use of a TLV orientated encoding was chosen to 260 match the Internet standard PA-TNC and PB-TNC protocols. Because the 261 PA-TNC, PB-TNC and PT-TLS protocols are typically implemented inside 262 the same process space, this allows a common set of message parsing 263 code to be used. Similarly creation of debugging tools is simplified 264 by the common encoding methodologies. TLV-based encoding was used in 265 each of the NEA protocols in part because it enables a very space 266 efficient representation on the network and is simpler to parse than 267 some other encodings to benefit lower powered (or battery 268 constrained) devices. 270 2.4. No Change to Base TLS Protocol 272 During the design of the PT-TLS protocol, several approaches were 273 considered with different costs and benefits. Several considered 274 approaches involved integrating the PT protocol into the TLS 275 handshake protocol. Because the PT protocol requires the underlying 276 TLS carrier to provide security protections, the PT protocol couldn't 277 operate before the cipher suites were negotiated and in use. One 278 option was to integrate into the TLS handshake protocol after the 279 ChangeCipherSpec phase allowing the PT message to be protected. The 280 benefit of this approach is that the assessment protocol could 281 operate below the application protocols allowing for easier 282 integration into applications. However, making this change would 283 require some extensions to the TLS handshake protocol standards and 284 existing widely deployed TLS implementations, so it wasn't clear that 285 the cost was warranted, particularly because the application 286 independence can also be offered by a shim library between the 287 application and TLS library that provides the PT protocol 288 encapsulation/decapsulation. 290 The other general approach considered was to have PT-TLS layer on top 291 of TLS as an application protocol (using the standard 292 application_data ContentType). This has the advantage that existing 293 TLS software could be used. However, the PB-TNC traffic would need 294 to be encapsulated/decapsulated by a new PT-TLS protocol layer before 295 being passed to the TLS library. This didn't seem like a significant 296 issue as PB-TNC is architected to layer on PT anyway. 298 After considering the different options, it was determined that 299 layering the PT protocol on top of the TLS protocol without requiring 300 current TLS protocol implementations to change met all the 301 requirements and offered the best path toward rapid adoption and 302 deployment. Therefore the following sections describe a PT protocol 303 that is carried on top of TLS. 305 3. PT-TLS Protocol 307 This section specifies the PT-TLS protocol, a Posture Transport (PT) 308 protocol carried by the Transport Layer Security (TLS) protocol over 309 a TCP/IP network. As shown in Figure 1, this protocol runs directly 310 on top of TLS as an application. This means PT-TLS is encapsulated 311 within the TLS Record Layer protocol using the standard ContentType 312 for applications (application_data). 314 +---------------------------------------------------------------+ 315 | TLV Encapsulation of PB-PA message | 316 +---------------------------------------------------------------+ 317 | TLS | 318 +---------------------------------------------------------------+ 319 | TCP | 320 +---------------------------------------------------------------+ 321 Figure 1: PT-TLS Layering Model 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 Initiator". The other party in the session (which receives the 337 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 In most cases the traditional methods of server certificate ID 367 validation will not apply when the NEA Server initiates the 368 connection. In this case, the NEA Client and Server need to follow 369 the certificate path validation rules in RFC 5280 [RFC5280]. In 370 addition, each side needs to be able to authorize its peer based upon 371 matching Subject and SubjectAltName fields for certificates issued by 372 a particular trust root. 374 Therefore, NEA Clients SHOULD be capable of establishing and holding 375 open a TLS session with the NEA Server immediately after obtaining 376 network access. A NEA Client MAY listen for connection requests from 377 the NEA Server and establish a new PT-TLS session when one does not 378 already exist. Having an existing PT-TLS session allows either party 379 to initiate an assessment without requiring the NEA Client to be 380 listening for new connection requests. In order to keep the TLS 381 session alive, the NEA Client and NEA Server SHOULD be capable of 382 supporting the TLS heartbeat protocol [RFC6520]. 384 3.1.2. Establish or Re-Use Existing PT-TLS Session 386 A single PT-TLS session can support multiple NEA assessments, which 387 can be started by either party (the PT-TLS Initiator or the PT-TLS 388 Responder). The party that starts a NEA assessment is known as the 389 "assessment initiator" and the other party is known as the 390 "assessment responder". 392 If the assessment initiator already has a PT-TLS session to the 393 assessment responder, the initiator can re-use this session; 394 otherwise, a new PT-TLS session must be established. 396 3.2. TCP Port Usage 398 In order for a PT-TLS Initiator to establish a TCP connection to a 399 PT-TLS Responder, the initiator needs to know the TCP port number on 400 which the responder is listening for assessment requests. Therefore, 401 this specification requests the IANA reserve a TCP port number for 402 use with the PT-TLS protocol upon publication of this specification 403 as an Internet standard RFC. 405 3.3. Preventing MITM Attacks with Channel Bindings 407 As described in the NEA Asokan Attack Analysis [ASOKAN], a 408 sophisticated MITM attack can be mounted against NEA systems. The 409 attacker forwards PA-TNC messages from a healthy machine through an 410 unhealthy one so that the unhealthy machine can gain network access. 411 Because there are easier attacks on NEA systems, like having the 412 unhealthy machine lie about its configuration, this attack is 413 generally only mounted against machines with an External Measurement 414 Agent (EMA). The EMA is a separate entity, difficult to compromise, 415 which measures and attests to the configuration of the endpoint. 417 To protect against NEA Asokan attacks, the Posture Broker Client on 418 an EMA-equipped endpoint should pass the tls-unique channel binding 420 [RFC5929] for PT-TLS's underlying TLS session to the EMA. This value 421 can then be included in the EMA's attestation and the Posture 422 Validator responsible for communicating with the EMA may then confirm 423 that the value matches the tls-unique channel binding for its end of 424 the connection. If the values match, the posture sent by the EMA and 425 NEA Client is from the same endpoint as the client side of the TLS 426 connection (since the endpoint knows the tls-unique value), so no 427 man-in-the-middle is forwarding posture. If they differ, an attack 428 has been detected. The Posture Validator MUST fail its verification 429 of the endpoint if an attack has been detected. 431 3.4. PT-TLS Message Flow 433 This section discusses the general flow of messages between the NEA 434 Client's Posture Transport Client and the NEA Server's Posture 435 Transport Server in order to perform NEA assessments using the PT-TLS 436 protocol. 438 3.4.1. Assessment Triggers 440 Initially, the NEA Client or NEA Server will decide that an 441 assessment is needed. What stimulates the decision to perform an 442 assessment is outside the scope of this specification, but some 443 examples include: 445 o NEA Server becoming aware of suspicious behavior on an endpoint 447 o NEA Server receiving new policies requiring immediate action 449 o NEA Client noticing a change in local security posture 451 o NEA Client wishing to access a protected network or resource 453 Because either the NEA Client or NEA Server can trigger the 454 establishment of the TLS session and initiate the assessment, this 455 document will use the terms "assessment initiator" and the 456 "assessment responder". This nomenclature allows either NEA 457 component to fill either of the PT-TLS roles. 459 3.4.2. PT-TLS Message Exchange Phases 461 The PT-TLS message exchange occurs in three distinct phases: 463 o TLS Setup (including TLS Handshake protocol) 464 o PT-TLS Negotiation 466 o PT-TLS Data Transport 468 The TLS Setup phase is responsible for the establishment of the TCP 469 connection and the TLS protections for the PT-TLS messages. The TLS 470 Setup phase normally starts with the establishment of a TCP 471 connection between the Posture Transport Client and Posture Transport 472 Server. The new connection triggers the TLS Handshake protocol to 473 establish the cryptographic protections for the TLS session. Once 474 the TLS setup phase has completed, the TLS session MUST NOT be 475 renegotiated. TLS session renegotiation MAY be used before the TLS 476 Setup phase ends and the PT-TLS Negotiation phase begins. This phase 477 also enables the establishment of the tls-unique shared secret. The 478 tls-unique shared secret can later be used by PA to protect against 479 some forms of man-in-the-middle attack. 481 The PT-TLS Negotiation phase is only performed at the start of the 482 first assessment on a TLS session. During this phase, the NEA Client 483 and NEA Server discover each other's PT-TLS capabilities and 484 establish a context that will apply to all future PT-TLS messages 485 sent over the TLS session. The PT-TLS Negotiation phase MUST NOT be 486 repeated after the session has entered the Data Transport phase. NEA 487 assessment messages (PB-TNC batches) MUST NOT be sent by the NEA 488 Client or NEA Server prior to the completion of the PT-TLS 489 Negotiation phase to ensure that the security protections for the 490 session are properly established and applied to the NEA assessment 491 messages. 493 Finally the Data Transport phase allows the NEA Client and NEA Server 494 to exchange PT messages under the protection of the TLS session 495 consistent with the capabilities established in earlier phases. The 496 exchanged messages can be a PT-TLS protected NEA assessment as 497 described in this specification or other vendor-defined PT-TLS 498 exchanged messages. 500 3.4.2.1. TLS Setup Phase 502 After a new TCP connection is established between the Posture 503 Transport Client and Posture Transport Server, a standard TLS 504 exchange is performed to negotiate a common security context for 505 protecting subsequent communications. As discussed in section 3.4.1, 506 the TCP connection establishment and/or the TLS handshake protocol 507 could be initiated by either the NEA Client or NEA Server. The most 508 common situation would be for the assessment initiator to trigger the 509 creation of the TCP connection and TLS handshake, so an assessment 510 could begin when no session already exists. When the NEA Server has 511 initiated the TLS Setup, the NEA Server is acting as a TLS client and 512 the NEA Client is the TLS server (accepting the inbound TLS session 513 request). The expected normal case is that the NEA Client initiates 514 this phase, so that the NEA Server is acting as the TLS server and 515 therefore the bootstrapping of the security of the TLS session is 516 using the NEA Server's certificate. Having the NEA Client initiate 517 the TLS session avoids the need for the NEA Client to also possess a 518 certificate. 520 During the TLS Setup phase of PT-TLS, the PT-TLS Initiator contacts 521 the listening port of the PT-TLS Responder and performs a TLS 522 handshake. The PT-TLS Responder MUST possess a trustworthy X.509 523 certificate used to authenticate to the TLS initiator and used to 524 bootstrap the security protections of the TLS session. The PT-TLS 525 Initiator MAY also use an X.509 certificate to authenticate to the 526 PT-TLS Responder providing for a bi-directional authentication of the 527 PT-TLS session. The NEA client MUST provide certificate validation 528 according to the rules in RFC 5280 when evaluating the server 529 certificate. In addition the NEA client MUST follow the 530 recommendations in RFC 6125 [RFC6125] when validating the NEA server 531 domain name against the contents of the server certificate. Details 532 for the reverse direction are given in section 3.1. 534 Due to deployment issues with issuing and distributing certificates 535 to a potentially large number of NEA Clients, this specification 536 allows the NEA Client to be authenticated during the PT-TLS 537 Negotiation phase using other more cost effective methods. At the 538 conclusion of a successful initial TLS Setup phase, the NEA Client 539 and NEA Server have a protected session to exchange messages. This 540 allows the protocol to transition to the PT-TLS Negotiation phase. 542 3.4.2.2. PT-TLS Negotiation Phase 544 Once a TLS session has been established between Posture Transport 545 Client and Posture Transport Server, the PT-TLS Initiator sends a 546 Version Request Message indicating its supported PT-TLS protocol 547 version range. Next, the PT-TLS Responder sends a Version Response 548 Message which selects a protocol version from within the range 549 offered. The PT-TLS Responder SHOULD select the preferred version 550 offered if supported; otherwise, the highest version that the 551 responder is able to support from the received Version Request 552 Message. If the PT-TLS Responder is unable or unwilling to support 553 any of the versions included in the Version Request Message, the 554 responder SHOULD send a Version Not Supported error message. 556 If no client side authentication occurred during the TLS Setup phase, 557 the Posture Transport Server can authenticate the client using PT-TLS 558 client authentication messages as described in section 3.8. The 559 NEA Server initiates the client authentication and indicates when the 560 authentication is complete. 562 When the NEA Client receives the SASL [RFC4422] Mechanisms list, the 563 NEA Client responds with a SASL Mechanism Selection TLV indicating 564 the method of authentication to be used. Upon selecting an 565 appropriate SASL mechanism, the NEA Client and Server exchange SASL 566 mechanism specific messages in order to authenticate the NEA Client. 567 When the client authentication successfully completes and no 568 additional authentications are required (as indicated by the NEA 569 Server sending an empty SASL Mechanisms list), the PT-TLS session 570 transitions into the Data Transport phase, where it will remain for 571 the duration of the session. Note that the NEA Server could choose 572 to not authenticate the client (indicated by only sending an empty 573 SASL Mechanisms list) or to continue performing a posture assessment 574 even if the authentication did not complete successfully. 576 3.4.2.3. PT-TLS Data Transport Phase 578 Once a PT-TLS session is available to carry NEA assessments, PT-TLS 579 allows either side of the connection to send the first PB-TNC batch. 580 The PB-TNC standard prescribes whether the Posture Broker Client or 581 Posture Broker Server starts the assessment. The assessment 582 initiator first envelopes the PB-TNC batch in a PT-TLS message, then 583 assigns a message identifier to the message and finally transmits it 584 over the session. The assessment responder validates the PT-TLS 585 message and delivers the encapsulated PB-TNC batch to its upstream 586 component (Posture Broker Client or Server). 588 Most PT-TLS messages contain PB-TNC batches that house PA-TNC 589 requests for posture information or a response containing the 590 requested posture information. The Posture Transport Client and 591 Posture Transport Server may also exchange messages between them, 592 such as a PT-TLS Error Message indicating that a problem occurred 593 processing a message. During an assessment, the Posture Transport 594 Client and Server merely encapsulate and exchange the PB-TNC batches 595 and are unaware of the state of the assessment. 597 The PT-TLS protocol allows either party to send a PT-TLS message at 598 any time, reflecting the full duplex nature of the underlying TLS 599 session. For example, an assessment initiator may send several PT- 600 TLS messages prior to receiving any responses from the assessment 601 responder. All implementations of PT-TLS MUST support full duplex 602 PT-TLS message exchange. However, some NEA protocols may not be able 603 to make use of the full-duplex message exchange. 605 3.4.3. TLS Requirements 607 In order to ensure that strong security is always available for 608 deployers and to improve interoperability, this section discusses 609 some requirements on the underlying TLS transport used by PT-TLS. 610 Implementations of PT-TLS MUST support use of TLS 1.1 [RFC4346] and 611 SHOULD also include support for TLS 1.2 [RFC5246]. For each TLS 612 version supported, implementations of the PT-TLS MUST at least 613 support the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite. This cipher 614 suite requires the server to provide a certificate that can be used 615 during the key exchange. Implementations SHOULD NOT include support 616 for cipher suites that do not minimally offer PT-TLS Responder 617 (typically Posture Transport Server) authentication, such as the 618 anonymous Diffie-Hellman cipher suites (e.g. 619 TLS_DH_anon_WITH_AES_128_CBC_SHA). Implementations MUST support RFC 620 5746 [RFC5746]. Implementations MAY allow renegotiation to provide 621 confidentiality for the client certificate. If renegotiation is 622 allowed implementations need to select the appropriate handshake 623 messages as described in RFC 5929 for the tls-unique value. 625 3.5. PT-TLS Message Format 627 This section describes the format and semantics of the PT-TLS 628 message. Every message sent over a PT-TLS session MUST start with 629 the PT-TLS header described in this section. 630 The following is the PT-TLS header: 632 1 2 3 633 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 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Reserved | Message Type Vendor ID | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Message Type | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Message Length | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Message Identifier | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Message Value (e.g. PB-TNC Batch) . . . | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 Reserved 648 Reserved for future use. This field MUST be set to 0 on 649 transmission and ignored upon reception. 651 Message Type Vendor ID 653 This field indicates the owner of the name space associated with 654 the Message Type. This is accomplished by specifying the 24 bit 655 SMI Private Enterprise Number (Vendor ID) of the party who owns 656 the Message Type name space. IETF Standard PT-TLS Message Types 657 MUST use zero (0) in this field. 659 The PT-TLS Message Type Vendor ID 0xffffff is reserved. Posture 660 Transport Clients and Servers MUST NOT send PT-TLS messages in 661 which the PT-TLS Message Type Vendor ID has this reserved value 662 (0xffffff). If a Posture Transport Client or Posture Transport 663 Server receives a message containing this reserved value 664 (0xffffff) in the PT-TLS Message Type Vendor ID, the recipient 665 SHOULD respond with an Invalid Parameter error code in a PT-TLS 666 Error message. 668 Message Type 670 This field defines the type of the PT-TLS message within the 671 scope of the specified Message Type Vendor ID that is included in 672 the Message Value field. The specific IETF standard values 673 allowable in this field when the Message Type Vendor ID is the 674 IETF SMI Private Enterprise Number value (0) are defined in 675 section 3.6. Recipients of a message containing a Message Type 676 Vendor ID and Message Type that is unrecognized SHOULD respond 677 with a Type Not Supported error code in a PT-TLS Error message. 679 Posture Transport Clients and Posture Transport Servers MUST NOT 680 require support for particular vendor-defined PT-TLS Message 681 Types and MUST interoperate with other parties despite any 682 differences in the set of vendor-defined PT-TLS Message Types 683 supported (although they MAY permit administrators to configure 684 them to require support for specific vendor-defined PT-TLS 685 message types). 687 If the PT-TLS Message Type Vendor ID field has the value zero 688 (0), then the PT-TLS Message Type field contains an IETF Standard 689 PT-TLS Message Type, as listed in the IANA registry. IANA 690 maintains a registry of PT-TLS Message Types. Entries in this 691 registry are added by Expert Review with Specification Required, 692 following the guidelines in section 6.1. Section 3.6. of this 693 specification defines the initial set of IETF Standard PT-TLS 694 Message Types. 696 The PT-TLS Message Type 0xffffffff is reserved. Posture 697 Transport Clients and Posture Transport Servers MUST NOT send PT- 698 TLS messages in which the PT-TLS Message Type has this reserved 699 value (0xffffffff). If a Posture Transport Client or Posture 700 Transport Server receives a message in which the PT-TLS Message 701 Type has this reserved value (0xffffffff), it SHOULD respond with 702 an Invalid Parameter error code in a PT-TLS Error message. 704 Message Length 706 This field contains the length in octets of the entire PT-TLS 707 message (including the entire header). Therefore, this value 708 MUST always be at least 16. Any Posture Transport Client or 709 Posture Transport Server that receives a message with a PT-TLS 710 Message Length field whose value is less than 16 SHOULD respond 711 with an Invalid Parameter PT-TLS error code. Similarly, if a 712 Posture Transport Client or Posture Transport Server receives a 713 PT-TLS message for a Message Type that has a known Message Length 714 and the Message Length indicates a different value (greater or 715 less than the expected value), the recipient SHOULD respond with 716 an Invalid Parameter PT-TLS error code. 718 Message Identifier 720 This field contains a value that uniquely identifies the PT-TLS 721 message on a per message sender (Posture Transport Client or 722 Server) basis. This value is copied into the body of the PT-TLS 723 Error Message so the recipient can determine which message caused 724 the error. 726 The Message Identifier MUST be a monotonically increasing counter 727 starting at zero indicating the number of the messages the sender 728 has transmitted over the TLS session. It is possible that a busy 729 or long lived session might exceed 2^32-1 messages sent, so the 730 message sender MUST roll over to zero upon reaching the 2^32nd 731 message, thus restarting the increasing counter. During a 732 rollover, it is feasible that the message recipient could be 733 confused if it keeps track of every previously received Message 734 Identifier, so recipients MUST be able to handle roll over 735 situations without generating errors. 737 Message Value 739 The contents of this field vary depending on the particular 740 Message Type Vendor ID and Message Type given in the PT-TLS 741 header for this PT-TLS message. This field most frequently 742 contains a PB-TNC batch. The contents of this field for each of 743 the IETF Standard PT-TLS Message Types are defined in this 744 specification. 746 3.6. IETF Standard PT-TLS Message Types 748 This section defines the NEA standard PT-TLS Message Types used to 749 carry PT-TLS messages and PB-TNC batches between the Posture 750 Transport Client and Posture Transport Server. 752 The following table summarizes the initial set of IETF standard 753 message type values, which are used with the PT-TLS Message Type 754 Vendor ID field set to the IETF SMI PEN (0). 756 Value (Name) Definition 757 ------------ ---------- 758 0 (Experimental) Reserved for experimental use. This 759 type will not offer interoperability 760 but allows for experimentation. This 761 message type MUST only be sent when 762 the NEA Client and NEA Server are in 763 the Data Transport phase and only on a 764 restricted, experimental network. 765 Production code MUST send an Invalid 766 Message error code in a PT-TLS Error 767 message if an Experimental message is 768 received. 770 1 (Version Request) Version negotiation request including 771 the range of versions supported by the 772 sender. This message type MUST only 773 be sent by the TLS session initiator 774 as the first PT-TLS message in the PT- 775 TLS Negotiation phase. Recipients 776 MUST send an Invalid Message error 777 code in a PT-TLS Error message if a 778 Version Request is received at another 779 time. 781 2 (Version Response) PT-TLS protocol version selected by 782 the responder. This message type MUST 783 only be sent by the TLS session 784 responder as the second message in the 785 PT-TLS Negotiation phase. Recipients 786 MUST send an Invalid Message error 787 code in a PT-TLS Error message if a 788 Version Response is received at 789 another time. 791 3 (SASL Mechanisms) Sent by the NEA Server to indicate 792 what SASL mechanisms it is willing to 793 use for authentication on this 794 session. This message type MUST only 795 be sent by the NEA Server in the PT- 796 TLS Negotiation phase. The NEA Client 797 MUST send an Invalid Message error 798 code in a PT-TLS Error message if a 799 SASL Mechanisms message is received at 800 another time. 802 4 (SASL Mechanism Selection) Sent by the NEA Client to select a 803 SASL mechanism from the list offered 804 by the NEA Server. This message type 805 MUST only be sent by the NEA Client in 806 the PT-TLS Negotiation phase. The NEA 807 Server MUST send an Invalid Message 808 error code in a PT-TLS Error message 809 if a SASL Mechanism Selection is 810 received after the PT-TLS Negotiation 811 phase. Once a SASL mechanism has been 812 selected, it may not change until the 813 mechanism completes either 814 successfully or as a failure. 816 5 (SASL Authentication Data) Opaque octets exchanged between the 817 NEA Client and NEA Server's SASL 818 mechanisms to perform the client 819 authentication. This message type 820 MUST only be sent during the PT-TLS 821 Negotiation phase. Recipients MUST 822 send an Invalid Message error code in 823 a PT-TLS Error message if a SASL 824 Authentication Data message is 825 received after the PT-TLS Negotiation 826 phase. 828 6 (SASL Result) Indicates the result code of the SASL 829 mechanism authentication. A success 830 result indicates that the NEA Client 831 and NEA Server will transition to the 832 Data Transport phase, thus allowing 833 the assessment to start. Note that 834 the NEA Server may choose to allow the 835 transition to Data Transport phase 836 even if authentication is unsuccessful 837 before making its access control 838 decision. This message type MUST only 839 be sent by the NEA Server when the NEA 840 Client and NEA Server are in the PT- 841 TLS Negotiation phase. The NEA Client 842 MUST send an Invalid Message error 843 code in a PT-TLS Error message if a 844 SASL Result is received after the PT- 845 TLS Negotiation phase. 847 7 (PB-TNC Batch) Contains a PB-TNC batch. For more 848 information on PB-TNC batches see 849 section 4 of the PB-TNC specification. 850 This message type MUST only be sent 851 when the NEA Client and NEA Server are 852 in the PT-TLS Data Transport phase. 853 Recipients SHOULD send an Invalid 854 Message error code in a PT-TLS Error 855 message if a PB-TNC Batch is received 856 outside of the Data Transport phase. 858 8 (PT-TLS Error) PT-TLS Error message as described in 859 section 3.9. This message type may be 860 used during any PT-TLS phase. 862 9+ (Reserved) These values are reserved for future 863 allocation following guidelines 864 defined in the IANA Considerations 865 section 6.1. Recipients of messages 866 of type 9 or higher that do not 867 support the PT-TLS Message Type Vendor 868 ID and PT-TLS Message Type of a 869 received PT-TLS message MUST respond 870 with a Type Not Supported PT-TLS error 871 code in a PT-TLS Error message. 873 3.7. PT-TLS Version Negotiation 875 This section describes the message format and semantics for the PT- 876 TLS protocol version negotiation. This exchange is used by the PT- 877 TLS Initiator to trigger a version negotiation at the start of an 878 assessment. The PT-TLS Initiator MUST send a Version Request message 879 as its first PT-TLS message and MUST NOT send any other PT-TLS 880 messages on this connection until it receives a Version Response 881 message or an Error message. The PT-TLS Responder MUST complete the 882 version negotiation (or cause an error) prior to sending or accepting 883 reception of any additional messages. After the successful 884 completion of the version negotiation, both the Posture Transport 885 Client and Posture Transport Server MUST only send messages compliant 886 with the negotiated protocol version. Subsequent assessments on the 887 same session MUST use the negotiated version number and therefore 888 MUST NOT send additional version negotiation messages. 890 3.7.1. Version Request Message 892 This message is sent by a PT-TLS Initiator as the first PT-TLS 893 message in a PT-TLS session. This message discloses the sender's 894 supported versions of the PT-TLS protocol. To ensure compatibility, 895 this message MUST always be sent using version 1 of the PT-TLS 896 protocol. Recipients of this message MUST respond with a Version 897 Response, or a PT-TLS Error message (Version Not Supported or Invalid 898 Message). The following diagram shows the format of the Version 899 Request Message: 901 1 2 3 902 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 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Reserved | Min Vers | Max Vers | Pref Vers | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 Reserved 909 Reserved for future use. This field MUST be set to 0 on 910 transmission and ignored upon reception. 912 Min Vers 914 This field contains the minimum version of the PT-TLS 915 protocol supported by the sender. This field MUST be set to 916 1 indicating support for the first version of PT-TLS. 917 However, future versions of this specification will probably 918 remove this requirement so PT-TLS Responders MUST be 919 prepared to receive other values. 921 Max Vers 923 This field contains the maximum version of the PT-TLS 924 protocol supported by the sender. This field MUST be set to 925 1 indicating support for the first version of PT-TLS. 926 However, future versions of this specification will probably 927 remove this requirement so PT-TLS Responders MUST be 928 prepared to receive other values. 930 Pref Vers 931 This field contains the sender's preferred version of the 932 PT-TLS protocol. This is a hint to the recipient that the 933 sender would like this version selected if supported. The 934 value of this field MUST fall within the range of Min Vers 935 to Max Vers. This field MUST be set to 1 indicating support 936 for the first version of PT-TLS. However, future versions 937 of this specification will probably remove this requirement 938 so PT-TLS Responders MUST be prepared to receive other 939 values. 941 3.7.2. Version Response Message 943 This message is sent in response to receiving a Version Request 944 Message at the start of a new assessment session. If a recipient 945 receives a Version Request after a successful version negotiation has 946 occurred on the session, the recipient SHOULD send an Invalid Message 947 error code in a PT-TLS Error message and have TLS close the session. 948 This message MUST be sent using the syntax, semantics, and 949 requirements of the protocol version specified in this message. 951 1 2 3 952 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 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | Reserved | Version | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 Reserved 959 Reserved for future use. This field MUST be set to 0 on 960 transmission and ignored upon reception. 962 Version 964 This field contains the version selected by the sender of 965 this message. The version selected MUST be within the Min 966 Vers to Max Vers inclusive range sent in the Version Request 967 Message. If a PT-TLS Initiator receives a message with an 968 invalid Version selected, the PT-TLS Initiator MUST respond 969 with a Version Not Supported PT-TLS error message. 971 3.8. Client Authentication using SASL 973 This section includes a description of the message format and 974 semantics necessary to perform client authentication 975 (authentication of the NEA Client) over PT-TLS. Client 976 authentication could be necessary if the NEA Server requires 977 such an authentication and it was not performed during the TLS 978 handshake. The general model used for performing an 979 authentication of the client using PT-TLS messages is to 980 integrate the Simple Authentication and Security Layer (SASL) 981 [RFC4422] framework. SASL provides a number of standards- 982 based authentication mechanisms capable of authenticating the 983 NEA Client using a variety of base technologies. 985 Client authentication may occur during the TLS handshake using 986 TLS defined authentication techniques. Because this client 987 authentication is optional, the NEA Server's policy may require 988 the client to be authenticated by PT-TLS before performing the 989 assessment. Similarly, the NEA Server may require a PT-TLS 990 authentication even if the NEA Client was authenticated during 991 the TLS handshake (e.g. to allow a user authentication after a 992 system level authentication occurred during the TLS handshake). 993 The decision of whether a SASL client authentication is to 994 occur is left to the NEA Server's policy. 996 As discussed in section 3.1.1, it is possible that the NEA 997 Server may initiate the TLS session to the NEA Client, thus 998 causing it to fill the role of TLS Client during the TLS 999 handshake. Because the NEA Server is required to possess an 1000 X.509 certificate for when it is acting as the TLS Server role 1001 (normal case), PT-TLS requires that the NEA Server MUST use its 1002 X.509 certificate for TLS client authentication during the TLS 1003 handshake to authenticate itself even when it is acting as the 1004 TLS Client. In this case, the NEA Client and NEA Server will 1005 authenticate using certificates during the TLS handshake, so 1006 the PT-TLS SASL client authentication might not be required 1007 unless NEA Server policy required an additional authentication 1008 of the NEA Client. Therefore, the normal usage for the SASL 1009 messages is when the NEA Client acted as the TLS client and did 1010 not authenticate during the TLS handshake. 1012 3.8.1. SASL Entity Authentication Requirements 1014 Implementations compliant with the PT-TLS specification MUST 1015 implement the SASL authentication messages described in this 1016 section. In order to ensure interoperability, all PT-TLS 1017 implementations compliant with this specification MUST at least 1018 support the PLAIN SASL mechanism [RFC4616]. Similarly, 1019 implementations MUST provide the EXTERNAL SASL mechanism if 1020 both parties are authenticated during the TLS establishment. 1021 In order to be able to take advantage of other strong, widely 1022 deployed authentication technologies such as Kerberos and 1023 support for channel bindings, implementations MAY include 1024 support for GS2 (second GSS-API bridge for SASL) [RFC5801]. 1025 GS2 includes negotiable support for channel binding for use 1026 with SASL (see section 5 of RFC 5801). 1028 3.8.2. SASL in PT-TLS Overview 1030 Mechanism negotiation is initiated by the NEA Server sending the SASL 1031 Mechanisms TLV to the NEA Client to indicate the zero or more SASL 1032 mechanisms the NEA Server's policy is willing to use with the NEA 1033 Client. The NEA Client selects one SASL mechanism from the list and 1034 sends a SASL Mechanism Selection TLV completing the negotiation. 1035 Subsequent challenges and responses are carried within the SASL 1036 Authentication Data TLV carrying the authentication data for the 1037 selected mechanism. The authentication outcome is communicated in a 1038 SASL Result TLV containing a status code. If additional 1039 authentications are required, the NEA Server could trigger the next 1040 authentication by sending another SASL Mechanisms TLV after sending 1041 the SASL Result TLV for the current authentication mechanism. 1043 3.8.3. SASL Authentication Flow 1045 The SASL client authentication starts when the NEA Server 1046 enters the PT-TLS Negotiation phase and its policy indicates 1047 that an authentication of the NEA Client is necessary but was 1048 not performed during the TLS handshake protocol. The NEA 1049 Server is responsible for triggering the client authentication 1050 by sending the SASL Mechanisms TLV to the NEA Client listing 1051 the set of SASL mechanisms the server is willing to use based 1052 upon its policy. 1054 The NEA Client selects a SASL mechanism from the list proposed 1055 by the NEA Server or sends a PT-TLS Invalid message error code 1056 indicating it is unable or unwilling to perform any of the 1057 mechanisms that were offered. If the NEA Server receives a 1058 SASL Mechanism Selection TLV that contains an unacceptable SASL 1059 mechanism, the NEA Server would respond with a SASL Mechanism 1060 Error in a PT-TLS Error TLV. 1062 In situations where the NEA Server does not require a client 1063 authentication (either authentication isn't necessary or was 1064 performed during the TLS Setup phase), the NEA Server MUST send 1065 a SASL Mechanisms TLV with no mechanisms included (only the PT- 1066 TLS header) indicating the connection should transition to the 1067 PT-TLS Data Transport phase. The same mechanism is employed to 1068 indicate that a SASL authentication already performed in this 1069 session is adequate to permit transition to the PT-TLS Data 1070 Transport phase. So the NEA Server MUST always send a SASL 1071 Mechanisms TLV with no mechanisms as the last message in the 1072 PT-TLS Negotiation phase and the NEA Client MUST NOT transition 1073 to the PT-TLS Data Transport phase until it receives such a 1074 message. 1076 If the NEA Server receives a NEA assessment message before the 1077 completion of the client authentication, the NEA Server MUST 1078 send an Authentication Required PT-TLS Error indicating to the 1079 NEA Client that an authentication exchange is required prior to 1080 entering the PT-TLS Data Transport phase. 1082 3.8.4. Aborting SASL Authentication 1084 The NEA Server may abort the authentication exchange by sending the 1085 SASL Result TLV with a status code of ABORT. The NEA Client may 1086 abort the authentication exchange by sending a PT-TLS Error message 1087 with an Error Code of SASL Mechanism Error. 1089 3.8.5. Linkages to SASL Framework 1091 3.8.5.1. SASL Service Name 1093 The service name for PT-TLS is "nea-pt-tls". 1095 3.8.5.2. SASL Authorization Identity 1097 The PT-TLS protocol does not make use of a SASL authorization 1098 identity string as described in RFC4422. 1100 3.8.5.3. SASL Security Layer 1102 The NEA PT-TLS protocol always runs under the protection of TLS. 1103 SASL security layers are not used and thus MUST be negotiated off 1104 during SASL authentication. 1106 3.8.5.4. Multiple Authentications 1108 Only one SASL mechanism authentication may be in progress at any one 1109 time. Once a SASL mechanism completes (successfully or 1110 unsuccessfully) the NEA Server may trigger an additional 1111 authentication by sending a SASL Mechanisms TLV. 1113 3.8.6. SASL Channel Bindings 1115 SASL channel bindings are used to bind the SASL authentication to the 1116 outer TLS tunnel to ensure that the authenticating endpoints are the 1117 same as the TLS endpoints. For SASL mechanisms that support channel 1118 bindings the TLS-unique value defined in RFC 5929 is carried by the 1119 SASL Mechanism. For most mechanisms this means including the tls- 1120 unique value with the appropriate prefix defined in RFC 5929 in the 1121 application data portion of the SASL Mechanism channel binding data. 1122 If the validation of the channel-binding fails then the connection 1123 MUST be aborted. 1125 3.8.7. SASL Mechanisms 1127 This TLV is sent by the NEA Server to indicate the list of SASL 1128 mechanisms that it is willing and able to use to authenticate the NEA 1129 Client. Each mechanism name consists of a length followed by a 1130 name. The total length of the list is determined by the TLV Length 1131 field. 1133 1 2 3 1134 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 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 | Rsvd| Mech Len| Mechanism Name (1-20 bytes) | 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 | Rsvd| Mech Len| Mechanism Name (1-20 bytes) | 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 | . . . . . . . . . . . | 1142 Rsvd (Reserved) 1144 Reserved for future use. This field MUST be set to 0 on 1145 transmission and ignored upon reception. 1147 Mech Len (Mechanism Name Length) 1149 The length of the Mechanism-Name field in octets. 1151 Mechanism Name 1153 SASL mechanism name adhering to the rules defined in 1154 RFC4422. 1156 3.8.8. SASL Mechanism Selection 1158 This TLV is sent by the NEA Client in order to select a SASL 1159 mechanism for use on this session. 1161 1 2 3 1162 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 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 | Rsvd| Mech Len| Mechanism Name (1-20 bytes) | 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 | Optional Initial Mechanism Response | 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 Rsvd (Reserved) 1171 Reserved for future use. This field MUST be set to 0 on 1172 transmission and ignored upon reception. 1174 Mech Len (Mechanism Name Length) 1176 The length of the Mechanism-Name field in octets. 1178 Mechanism Name 1180 SASL mechanism name adhering to the rules defined in 1181 RFC4422. 1183 Optional Initial Mechanism Response 1185 Initial set of authentication information required from the 1186 NEA Client to kick start the authentication. This data is 1187 optional and if not provided would be solicited by the NEA 1188 Server in the first SASL Authentication Data TLV request. 1190 3.8.9. SASL Authentication Data 1192 This TLV carries an opaque (to PT-TLS) blob of octets being exchanged 1193 between the NEA Client and the NEA Server. This TLV facilitates 1194 their communications without interpreting any of the bytes. The SASL 1195 Authentication Data TLV MUST NOT be sent until a SASL mechanism has 1196 been established for a session. The SASL Authentication Data TLV 1197 associated with the current authentication mechanism MUST NOT be sent 1198 after a SASL Result is sent with a Successful status. Additional 1199 SASL Authentication Data TLVs would be sent if the PT-TLS Initiator 1200 and Responder desire a subsequent SASL authentication to occur but 1201 only after another SASL mechanism selection exchange occurs. 1203 1 2 3 1204 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 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 ~ SASL Mechanism Data (Variable Length) ~ 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 SASL Mechanism Data 1210 Opaque, variable length set of bytes exchanged between the 1211 PT-TLS Initiator's SASL mechanism and its peer PT-TLS 1212 Responder's SASL mechanism. These bytes MUST NOT be 1213 interpreted by the PT-TLS layer. 1215 3.8.10. SASL Result 1217 This TLV is sent by the NEA Server at the conclusion of the SASL 1218 exchange to indicate the authentication result. Upon reception of a 1219 SASL Result TLV indicating an Abort, the NEA Client MUST terminate 1220 the current authentication conversation. The recipient may retry the 1221 authentication in the event of an authentication failure. Similarly, 1222 the NEA Server may request additional SASL authentication(s) be 1223 performed after the completion of a SASL mechanism by sending another 1224 SASL Mechanisms TLV including any mechanisms dictated by its policy. 1226 1 2 3 1227 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 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 | Result Code | Optional Result Data | 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1231 | . . . . . . . . . . . | 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 Result Code 1236 This field contains the result of the SASL authentication 1237 exchange. 1239 Value (Name) Definition 1240 ------------ ---------- 1241 0 (Success) SASL authentication was successful and 1242 identity was confirmed. 1244 1 (Failure) SASL authentication failed. This 1245 might be caused by the client 1246 providing an invalid user identity 1247 and/or credential pair. Note that 1248 this is not a mechanism failure to 1249 process the authentication as reported 1250 by the Mechanism Failure code. 1252 2 (Abort) SASL authentication exchange was 1253 aborted by the sender 1255 3 (Mechanism Failure) SASL "mechanism failure" during the 1256 processing of the client's 1257 authentication (e.g. not related to 1258 the user's input). 1260 Optional Result Data 1262 This field contains a variable length set of additional data 1263 for a successful result. This field MUST be zero length 1264 unless the NEA Server is returning a Result Code of Success 1265 and has more data to return. For more information on the 1266 additional data with success in SASL, see RFC 4422. 1268 3.9. Error Message 1270 This section describes the format and contents of the PT-TLS Error 1271 Message sent by the NEA Client or NEA Server when it detects a PT-TLS 1272 level protocol error. Each error message contains an error code 1273 indicating the error that occurred, followed by a copy of the message 1274 that caused the error. 1276 When a PT-TLS error is received, the recipient MUST NOT respond with 1277 a PT-TLS error because this could result in an infinite loop of error 1278 messages being sent. Instead, the recipient MAY log the error, 1279 modify its behavior to avoid future errors, ignore the error, 1280 terminate the assessment, or take other action as appropriate (as 1281 long as it is consistent with the requirements of this 1282 specification). 1284 The Message Value portion of a PT-TLS Error Message contains the 1285 following information: 1287 1 2 3 1288 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 1289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1290 | Reserved | Error Code Vendor ID | 1291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1292 | Error Code | 1293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1294 | Copy of Original Message (Variable Length) | 1295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 | . . . . . . . | 1298 Reserved 1300 Reserved for future use. This field MUST be set to 0 on 1301 transmission and ignored upon reception. 1303 Error Code Vendor ID 1305 This field contains the IANA assigned SMI Private Enterprise 1306 Number for the vendor whose Error Code name space is being 1307 used in the message. For IETF standard Error Code values 1308 this field MUST be set to zero (0). For other vendor- 1309 defined Error Code name spaces this field MUST be set to the 1310 SMI Private Enterprise Number of the vendor. 1312 Error Code 1314 This field contains the error code. This error code exists 1315 within the scope of Error Code Vendor ID in this message. 1316 Posture Transport Clients and Posture Transport Servers MUST 1317 NOT require support for particular vendor-specific PT-TLS 1318 Error Codes and MUST interoperate with other parties despite 1319 any differences in the set of vendor-specific PT-TLS Error 1320 Codes supported (although they MAY permit administrators to 1321 configure them to require support for specific PT-TLS error 1322 codes). 1324 When the Error Code Vendor ID is set to the IETF Private 1325 Enterprise Number, the following table lists the supported 1326 IETF standard numeric error codes: 1328 Value (Name) Definition 1329 ------------ ---------- 1330 0 (Reserved) Reserved value indicates that the PT- 1331 TLS Error Message SHOULD be ignored by 1332 all recipients. This MAY be used for 1333 debugging purposes to allow a sender 1334 to see a copy of the message that was 1335 received while a receiver is operating 1336 on its contents. 1338 1 (Malformed Message) PT-TLS message unrecognized or 1339 unsupported. This error code SHOULD 1340 be sent when the basic message content 1341 sanity test fails. The sender of this 1342 error code MUST consider it a fatal 1343 error and abort the assessment. 1345 2 (Version Not Supported) This error SHOULD be sent when a PT- 1346 TLS Responder receives a PT-TLS 1347 Version Request message containing a 1348 range of version numbers that doesn't 1349 include any version numbers that the 1350 recipient is willing and able to 1351 support on the session. All PT-TLS 1352 messages carrying the Version Not 1353 Supported error code MUST use a 1354 Version number of 1. All parties that 1355 receive or send PT-TLS messages MUST 1356 be able to properly process an error 1357 message that meets this description, 1358 even if they cannot process any other 1359 aspect of PT-TLS version 1. The 1360 sender and receiver of this error code 1361 MUST consider this a fatal error and 1362 close the TLS session after sending or 1363 receiving this PT-TLS message. 1365 3 (Type Not Supported) PT-TLS message type unknown or not 1366 supported. When a recipient receives 1367 a PT-TLS message type that it does not 1368 support, it MUST send back this error, 1369 ignore the message and proceed. For 1370 example, this could occur if the 1371 sender used a Vendor ID for the 1372 Message Type that is not supported by 1373 the recipient. This error message 1374 does not indicate a fatal error has 1375 occurred, so the assessment is allowed 1376 to continue. 1378 4 (Failed Authentication) The authentication of the identity of 1379 the client failed. This could occur 1380 if the SASL mechanism was unable to 1381 authenticate the claimed identity of 1382 the PT-TLS Initiator. This error 1383 message does not indicate a fatal 1384 error has occurred, so the 1385 authentication is allowed to be re- 1386 started. 1388 5 (Invalid Message) PT-TLS message received was invalid 1389 based on the protocol state. For 1390 example, this error would be sent if a 1391 recipient receives a message 1392 associated with the PT-TLS Negotiation 1393 Phase (such as Version messages) after 1394 the protocol has reached the PT-TLS 1395 Data Transport Phase. The sender and 1396 receiver of this error code MUST 1397 consider it a fatal error and close 1398 the TLS session after sending or 1399 receiving this PT-TLS message. 1401 6 (SASL Mechanism Error) A fatal error occurred while trying to 1402 perform the client authentication. 1403 For example, the NEA Client is unable 1404 to support any of the offered SASL 1405 mechanisms. The sender and receiver 1406 of this error code MUST consider it a 1407 fatal error and close the TLS session 1408 after sending or receiving this PT-TLS 1409 message. 1411 7 (Authentication Needed) The PT-TLS Responder has received a 1412 NEA assessment message before the 1413 completion of the client 1414 authentication. This could occur if 1415 the NEA Client initiated the PT-TLS 1416 session and then started sending PB 1417 messages before a required (by NEA 1418 Server policy) client authentication 1419 was performed. When the PT-TLS 1420 Initiator (typically NEA Client) 1421 receives this error, it should 1422 initiate an client authentication as 1423 discussed in 3.8.3. 1425 Copy of Original Message 1427 This variable length value MUST contain a copy (up to 1024 1428 bytes) of the original PT-TLS message that caused the error. 1429 If the original message is longer than 1024 bytes, only the 1430 initial 1024 bytes will be included in this field. This 1431 field is included so the error recipient can determine which 1432 message sent caused the error. In particular, the recipient 1433 can use the Message Identifier field from the Copy of 1434 Original Message to determine which message caused the 1435 error. 1437 4. Security Considerations 1439 This section discusses the major threats potentially faced by each 1440 binding of the PT protocol and countermeasures provided by the PT-TLS 1441 protocol. 1443 4.1. Trust Relationships 1445 In order to understand where security countermeasures are necessary, 1446 this section starts with a discussion of where the NEA architecture 1447 envisions some trust relationships between the processing elements of 1448 the PT-TLS protocol. The following sub-sections discuss the trust 1449 properties associated with each portion of the NEA reference model 1450 directly involved with the processing of the PT-TLS protocol. 1452 4.1.1. Posture Transport Client 1454 The Posture Transport Client is trusted by the Posture Broker Client 1455 to: 1457 o Not observe, fabricate or alter the contents of the PB-TNC batches 1458 received from the network 1460 o Not observe, fabricate or alter the PB-TNC batches passed down 1461 from the Posture Broker Client for transmission on the network 1463 o Transmit on the network any PB-TNC batches passed down from the 1464 Posture Broker Client 1466 o Deliver properly security protected messages received from the 1467 network that are destined for the Posture Broker Client 1469 o Provide configured security protections (e.g. authentication, 1470 integrity and confidentiality) for the Posture Broker Client's PB- 1471 TNC batches sent on the network 1473 o Expose the authenticated identity of the Posture Transport Server 1474 only to the PB-TNC layer within the NEA Client 1476 o Verify the security protections placed upon messages received from 1477 the network to ensure the messages are authentic and protected 1478 from attacks on the network 1480 o Provide a secure, reliable, in order delivery, full duplex 1481 transport for the Posture Broker Client's messages 1483 The Posture Transport Client is trusted by the Posture Transport 1484 Server to: 1486 o Not send malicious traffic intending to harm (e.g. denial of 1487 service) the Posture Transport Server 1489 o Not send malformed messages (e.g. messages lacking PT-TLS header) 1490 o Not send invalid or incorrect responses to messages (e.g. errors 1491 when no error is warranted) 1493 o Not ignore or drop messages causing issues for the protocol 1494 processing (e.g. dropping PT-TLS SASL Authentication Data 1495 messages) 1497 o Verify the security protections placed upon messages received from 1498 the network to ensure the messages are authentic and protected 1499 from attacks on the network 1501 4.1.2. Posture Transport Server 1503 The Posture Transport Server is trusted by the Posture Broker Server 1504 to: 1506 o Not observe, fabricate or alter the contents of the PB-TNC batches 1507 received from the network 1509 o Not observe, fabricate or alter the PB-TNC batches passed down 1510 from the Posture Broker Server for transmission on the network 1512 o Transmit on the network any PB-TNC batches passed down from the 1513 Posture Broker Server 1515 o Deliver properly security protected messages received from the 1516 network that are destined for the Posture Broker Server 1518 o Provide configured security protections (e.g. authentication, 1519 integrity and confidentiality) for the Posture Broker Server's 1520 messages sent on the network 1522 o Expose the authenticated identity of the Posture Transport Client 1523 only to the PB-TNC layer within the NEA Server 1525 o Verify the security protections placed upon messages received from 1526 the network to ensure the messages are authentic and protected 1527 from attacks on the network 1529 o Provide a secure, reliable, in order delivery, full duplex 1530 transport for the Posture Broker Server's messages 1532 The Posture Transport Server is trusted by the Posture Transport 1533 Client to: 1535 o Not send malicious traffic intending to harm (e.g. denial of 1536 service) the Posture Transport Server 1538 o Not send malformed messages (e.g. messages lacking PT-TLS header) 1540 o Not send invalid or incorrect responses to messages (e.g. errors 1541 when no error is warranted) 1543 o Not ignore or drop messages causing issues for the protocol 1544 processing (e.g. dropping PT-TLS SASL Result messages) 1546 o Verify the security protections placed upon messages received from 1547 the network to ensure the messages are authentic and protected 1548 from attacks on the network 1550 4.2. Security Threats and Countermeasures 1552 Beyond the trusted relationships assumed in section 4.1 the PT-TLS 1553 protocol faces a number of potential security attacks that could 1554 require security countermeasures. 1556 Generally, the PT-TLS protocol is responsible for offering strong 1557 security protections for all of the NEA protocols so any threats to 1558 its ability to protect NEA protocol messages could be very damaging 1559 to deployments. Once the message is delivered to the Posture Broker 1560 Client or Posture Broker Server, the posture brokers are trusted to 1561 properly and safely process the messages. 1563 4.2.1. Message Theft 1565 When PT-TLS messages are sent over unprotected network links or 1566 spanning local software stacks that are not trusted, the contents of 1567 the messages may be subject to information theft by an intermediary 1568 party. This theft could result in information being recorded for 1569 future use or analysis by the adversary. Messages observed by 1570 eavesdroppers could contain information that exposes potential 1571 weaknesses in the security of the endpoint, or system fingerprinting 1572 information easing the ability of the attacker to employ attacks more 1573 likely to be successful against the endpoint. The eavesdropper might 1574 also learn information about the endpoint or network policies that 1575 either singularly or collectively is considered sensitive 1576 information. For example, if PT-TLS does not provide confidentiality 1577 protection, an adversary could observe the PA-TNC attributes included 1578 in the PT-TLS message and determine that the endpoint is lacking 1579 patches, or particular sub-networks have more lenient policies. 1581 In order to protect against NEA assessment message theft, the PT-TLS 1582 protocol provides strong cryptographic authentication, integrity and 1583 confidentiality protection. Deployers are strongly encouraged to 1584 employ best practice of the day TLS ciphers to ensure the information 1585 remains safe despite advances in technology and discovered cipher 1586 weaknesses. The use of bi-directional authentication of the 1587 assessment transport session ensures that only properly authenticated 1588 and authorized parties may be involved in an assessment dialog. The 1589 PT-TLS protocol also provides strong cryptography for all of the PB- 1590 TNC and PA-TNC protocol messages traveling over the network allowing 1591 the message contents to be hidden from potential theft by the 1592 adversary even if the attacker is able to observe the encrypted PT- 1593 TLS session. 1595 4.2.2. Message Fabrication 1597 Attackers on the network or present within the NEA system could 1598 introduce fabricated PT-TLS messages intending to trick or create a 1599 denial of service against aspects of an assessment. For example, an 1600 adversary could attempt to insert into the message exchange fake PT- 1601 TLS error codes in order to disrupt communications. 1603 The PT-TLS protocol provides strong security protections for the 1604 complete message exchange over the network. These security 1605 protections prevent an intermediary from being able to insert fake 1606 messages into the assessment. In particular, the TLS's protocol use 1607 of hashing algorithms provides strong integrity protections that 1608 allow for detection of any changes in the content of the message 1609 stream. Additionally, adversaries are unable to observe the PT-TLS 1610 protocol exchanges because they are encrypted by the TLS ciphers, so 1611 would have difficulty in determining where to insert the falsified 1612 message, since the attacker is unable to determine where the message 1613 boundaries exist. Even a successful message insertion did occur; the 1614 recipient would be able to detect it due to the TLS cipher suite's 1615 integrity checking failing. 1617 4.2.3. Message Modification 1619 This attack could allow an active attacker capable of intercepting a 1620 message to modify a PT-TLS message or transported PA-TNC attribute to 1621 a desired value to ease the compromise of an endpoint. Without the 1622 ability for message recipients to detect whether a received message 1623 contains the same content as what was originally sent, active 1624 attackers can stealthily modify the attribute exchange. 1626 The PT-TLS protocol leverages the TLS protocol to provide strong 1627 authentication and integrity protections as a countermeasure to this 1628 theat. The bi-directional authentication prevents the attacker from 1629 acting as an active man-in-the-middle to the protocol that could be 1630 used to modify the message exchange. The strong integrity 1631 protections (e.g. hashing) offered by TLS allows PT-TLS message 1632 recipients to detect message alterations by other types of network 1633 based adversaries. 1635 4.2.4. Denial of Service 1637 A variety of types of denial of service attacks are possible against 1638 the PT-TLS protocol if the message exchanges are left unprotected 1639 while traveling over the network. The Posture Transport Client and 1640 Posture Transport Server are trusted not to participate in the denial 1641 of service of the assessment session, leaving the threats to come 1642 from the network. 1644 The PT-TLS protocol provides bi-directional authentication 1645 capabilities in order to prevent a man-in-the-middle on the network 1646 from becoming an undetected active proxy of PT-TLS messages. Because 1647 the PT-TLS protocol runs after the TLS handshake and thus cipher 1648 establishment/use, all of the PT-TLC messages are protected from 1649 undetected modification that could create a denial of service 1650 situation. However it is possible for an adversary to alter the 1651 message flows causing each message to be rejected by the recipient 1652 because it fails the integrity checking. 1654 The PT-TLS protocol operates as an application protocol on top of TLS 1655 and thus TCP/IP protocols, so is subject to denial of service attacks 1656 against the TLS, TCP and IP protocols. 1658 4.2.5. NEA Asokan Attacks 1660 As described in section 3.3 and in the NEA Asokan Attack Analysis 1661 [ASOKAN], a sophisticated MITM attack can be mounted against NEA 1662 systems. The attacker forwards PA-TNC messages from a healthy 1663 machine through an unhealthy one so that the unhealthy machine can 1664 gain network access. Section 3.3. and the NEA Asokan Attack Analysis 1665 provide a detailed description of this attack and of the 1666 countermeasures that can be employed against it. 1668 Because lying endpoint attacks are much easier than Asokan attacks 1669 and the only known effective countermeasure against lying endpoint 1670 attacks is the use of an External Measurement Agent (EMA), 1671 countermeasures against an Asokan attack are not necessary unless an 1672 EMA is in use. However, PT-TLS implementers may not know whether an 1673 EMA will be used with their implementation. Therefore, PT-TLS 1674 implementers SHOULD support the Asokan attack countermeasures 1675 described in section 3.3 by providing the value of the tls-unique 1676 channel binding to higher layers in the NEA reference model: Posture 1677 Broker Clients, Posture Broker Servers, Posture Collectors, and 1678 Posture Validators. 1680 The Asokan attack can also apply to authentication mechanisms carried 1681 within TLS. SASL mechanisms providing channel bindings use the tls- 1682 unique channel binding data as defined in section 3.3 to protect 1683 against the attack. 1685 4.2.6. Trust Anchors 1687 The TLS protocol bases its trust decision about the signer of the 1688 certificates received during the TLS authentication using a set of 1689 trust anchor certificate. It is essential that these trust anchor 1690 certificates are integrity protected from unauthorized modification. 1691 Many common software components (e.g. browsers, operating systems, 1692 security protocols) include a set of trust anchor certificates that 1693 are relevant to their operation. The PT-TLS SHOULD use a PT-TLS 1694 specific set of trust anchor certificates in order to limit what 1695 Certificate Authorities are authorized to issue certificates for use 1696 with NEA. 1698 5. Privacy Considerations 1700 The role of PT-TLS is to act as a secure transport for PB-TNC and 1701 other higher layer protocols. As such, PT-TLS does not directly 1702 utilize personally identifiable information (PII) except when client 1703 authentication is enabled. When client authentication is being used, 1704 the NEA Client will be asked to use SASL which may disclose a local 1705 identifier (e.g. username) associated with the endpoint and an 1706 authenticator (e.g. password) to authenticate that identity. Because 1707 the identity and authenticator are potentially privacy sensitive 1708 information, the NEA Client MUST offer a mechanism to restrict which 1709 NEA Servers will be sent this information. Similarly, the NEA Client 1710 should provide an indication to the person being identified that a 1711 request for their identity has been made in case they choose to opt 1712 out of the authentication to remain anonymous. 1714 PT-TLS provides cryptographic peer authentication, message integrity 1715 and data confidentiality protections to higher layer NEA protocols 1716 that may exchange data potentially including PII. These security 1717 services can be used to protect any PII involved in an assessment 1718 from passive and active attackers on the network. Endpoints sending 1719 potentially privacy sensitive information should ensure that the PT- 1720 TLS security protections (TLS cipher suites) negotiated for an 1721 assessment of the endpoint are adequate to avoid interception and 1722 off-line attacks of any long term privacy sensitive information. 1724 6. IANA Considerations 1726 This specification requests the creation of two new IANA 1727 registries and the assignment of a TCP port number. First, this 1728 specification requests the IANA reserve a registered TCP port 1729 number for use with the PT-TLS protocol upon publication of 1730 this specification as an Internet standard RFC. 1732 This section also defines the contents of two new IANA 1733 registries: PT-TLS Message Types, and PT-TLS Error Codes. This 1734 section explains how these registries work. 1736 All of the registries defined in this document support IETF 1737 standard values and vendor-defined values. To explain this 1738 phenomenon, we will use the PT-TLS Message Type as an example 1739 but the other registries work the same way. 1741 Whenever a PT-TLS Message Type appears on a network, it is 1742 always accompanied by an SMI Private Enterprise Number (PEN), 1743 also known as a vendor ID. If this vendor ID is zero, the 1744 accompanying PT-TLS Message Type is an IETF standard value 1745 listed in the IANA registry for PT-TLS Message Types and its 1746 meaning is defined in the specification listed for that PT-TLS 1747 Message Type in that registry. If the vendor ID is not zero, 1748 the meaning of the PT-TLS Message Type is defined by the vendor 1749 identified by the vendor ID (as listed in the IANA registry for 1750 SMI PENs). The identified vendor is encouraged but not required 1751 to register with IANA some or all of the PT-TLS Message Types 1752 used with their vendor ID and publish a specification for each 1753 of these values. 1755 This delegation of namespace is analogous to the technique used 1756 for OIDs. It can result in interoperability problems if 1757 vendors require support for particular vendor-specific values. 1758 However, such behavior is explicitly prohibited by this 1759 specification, which dictates that "Posture Transport Clients 1760 and Posture Transport Servers MUST NOT require support for 1761 particular vendor-specific PT-TLS Error Codes and MUST 1762 interoperate with other parties despite any differences in the 1763 set of vendor-specific PT-TLS Error Codes supported (although 1764 they MAY permit administrators to configure them to require 1765 support for specific PT-TLS error codes)." Similar requirements 1766 are included for PT-TLS Message Types and PT-TLS Auth Types. 1768 6.1. Designated Expert Guidelines 1770 For all of the IANA registries defined by this specification, 1771 new values are added to the registry by Expert Review with 1772 Specification Required, using the Designated Expert process 1773 defined in RFC 5226 [RFC5226]. 1775 This section provides guidance to designated experts so that 1776 they may make decisions using a philosophy appropriate for 1777 these registries. 1779 The registries defined in this document have plenty of values. 1780 In most cases, the IETF has approximately 2^32 values available 1781 for it to define and each vendor has the same number of values 1782 for its use. Because there are so many values available, 1783 designated experts should not be terribly concerned about 1784 exhausting the set of values. 1786 Instead, designated experts should focus on the following 1787 requirements. All values in these IANA registries MUST be 1788 documented in a specification that is permanently and publicly 1789 available. IETF standard values MUST also be useful, not 1790 harmful to the Internet, and defined in a manner that is clear 1791 and likely to ensure interoperability. 1793 Designated experts should encourage vendors to avoid defining 1794 similar but incompatible values and instead agree on a single 1795 IETF standard value. However, it is beneficial to document 1796 existing practice. 1798 There are several ways to ensure that a specification is 1799 permanently and publicly available. It may be published as an 1800 RFC. Alternatively, it may be published in another manner that 1801 makes it freely available to anyone. However, in this latter 1802 case, the vendor MUST supply a copy to the IANA and authorize 1803 the IANA to archive this copy and make it freely available to 1804 all if at some point the document becomes no longer freely 1805 available to all through other channels. 1807 The following three sections provide guidance to the IANA in 1808 creating and managing the new IANA registries defined by this 1809 specification. 1811 6.2. Registry for PT-TLS Message Types 1813 The name for this registry is "PT-TLS Message Types". Each 1814 entry in this registry should include a human-readable name, an 1815 SMI Private Enterprise Number, a decimal integer value between 1816 0 and 2^32-1, and a reference to the specification where the 1817 contents of this message type are defined. This specification 1818 must define the meaning of the PT-TLS message type and the 1819 format and semantics of the PT-TLS Message Value field that 1820 include the designated Private Enterprise Number in the PT-TLS 1821 Message Type Vendor ID field and the designated numeric value 1822 in the PT-TLS Message Type field. 1824 The following entries for this registry are defined in this 1825 document. Once this document becomes an RFC, they should 1826 become the initial entries in the registry for PT-TLS Message 1827 Types. Additional entries to this registry are added by Expert 1828 Review with Specification Required, following the guidelines in 1829 section 6.1. 1831 PEN Value Name Defining Specification 1832 --- ----- ---- ---------------------- 1833 0 0 Experimental RFC # Assigned to this I-D 1834 0 1 Version Request RFC # Assigned to this I-D 1835 0 2 Version Response RFC # Assigned to this I-D 1836 0 3 SASL Mechanisms RFC # Assigned to this I-D 1837 0 4 SASL Mechanism Selection RFC # Assigned to this I-D 1838 0 5 SASL Authentication Data RFC # Assigned to this I-D 1839 0 6 SASL Result RFC # Assigned to this I-D 1840 0 7 PB-TNC Batch RFC # Assigned to this I-D 1841 0 8 PT-TLS Error RFC # Assigned to this I-D 1842 0 9+ Reserved RFC # Assigned to this I-D 1844 6.3. Registry for PT-TLS Error Codes 1846 The name for this registry is "PT-TLS Error Codes". Each entry 1847 in this registry should include a human-readable name, an SMI 1848 Private Enterprise Number, a decimal integer value between 0 1849 and 2^32-1, and a reference to the specification where this 1850 error code is defined. This specification must define the 1851 meaning of this error code and the format and semantics of the 1852 Error Information field for PT-TLS messages that have a PT-TLS 1853 Vendor ID of 0, a PT-TLS Message Type of PT-TLS Error, the 1854 designated Private Enterprise Number in the PT-TLS Error Code 1855 Vendor ID field, and the designated numeric value in the PT-TLS 1856 Error Code field. 1858 The following entries for this registry are defined in this 1859 document. Once this document becomes an RFC, they should 1860 become the initial entries in the registry for PT-TLS Error 1861 Codes. Additional entries to this registry are added by Expert 1862 Review with Specification Required, following the guidelines in 1863 section 6.1. 1865 PEN Value Name Defining Specification 1866 --- ----- ---- ---------------------- 1867 0 0 Reserved RFC # Assigned to this I-D 1868 0 1 Malformed Message RFC # Assigned to this I-D 1869 0 2 Version Not Supported RFC # Assigned to this I-D 1870 0 3 Type Not Supported RFC # Assigned to this I-D 1871 0 4 Failed Authentication RFC # Assigned to this I-D 1872 0 5 Invalid Message Error RFC # Assigned to this I-D 1873 0 6 SASL Mechanism Error RFC # Assigned to this I-D 1874 0 7 Authentication Needed RFC # Assigned to this I-D 1875 0 8+ Reserved RFC # Assigned to this I-D 1877 7. Acknowledgments 1879 Thanks to the Trusted Computing Group for contributing the initial 1880 text upon which this document was based [IFT-TLS]. 1882 The authors of this draft would also like to acknowledge the 1883 following people who have contributed to or provided substantial 1884 input on the preparation of this document or predecessors to it: Syam 1885 Appala, Stuart Bailey, Lauren Giroux, Steve Hanna, Josh Howlett, 1886 Carolin Latze, Scott Kelly, Sung Lee, Lisa Lorenzin, Ravi Sahita, 1887 Subbu Srinivasan, Susan Thomson and Mark Townsend. 1889 This document was prepared using 2-Word-v2.0.template.dot. 1891 8. References 1893 8.1. Normative References 1895 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1896 Requirement Levels", BCP 14, RFC 2119, March 1997. 1898 [RFC4346] Dierks T., Rescorla E., "The Transport Layer Security (TLS) 1899 Protocol Version 1.1", RFC 4346, April 2006. 1901 [RFC4422] Melnikov A., Zeilenga K., "Simple Authentication and 1902 Security Layer (SASL)", RFC 4422, June 2006. 1904 [RFC4616] Zeilenga K., "The PLAIN Simple Authentication and Security 1905 Layer (SASL) Mechanism", RFC 4616, August 2006. 1907 [RFC5226] Narten T., Alvestrand H., "Guidelines for Writing an IANA 1908 Considerations Section in RFCs", RFC 5226, May 2008. 1910 [RFC5246] Dierks T., Rescorla E., "The Transport Layer Security (TLS) 1911 Protocol Version 1.2", RFC 5246, August 2008. 1913 [RFC5280] Cooper, D., Santesson, S., Farrel, S., Boeyen, S., Housley, 1914 R., Polk, W., "Internet X.509 Public Key Infrastructure 1915 Certificate and Certificate Revocation List (CRL) Profile", 1916 RFC 5280, May 2008. 1918 [RFC5746] Rescorla E., Ray M., Oskov N., "Transport Layer Security 1919 (TLS) Renegotiation Indication Extension", RFC 5746, 1920 February 2010. 1922 [RFC5792] Sangster P., Narayan K., "PA-TNC: A Posture Attribute 1923 Protocol (PA) Compatible with TNC", RFC 5792, March 2010. 1925 [RFC5793] Sahita, R., Hanna, S., and R. Hurst, "PB-TNC: A Posture 1926 Broker Protocol (PB) Compatible with TNC", RFC 5793, March 1927 2010. 1929 [RFC5929] Altman, J., Williams, N., Zhu L., "Channel Bindings for 1930 TLS", RFC 5929, July 2010. 1932 [RFC6125] Saint-Andre, P., Hodges, J., "Representation and 1933 Verification of Domain-Based Application Service Identity 1934 within Internet Public Key Infrastructure Using X.509 1935 (PKIX) Certificates in the Context of Transport Layer 1936 Security (TLS)", RFC 6125, March 2011. 1938 [RFC6520] Segglemann, R., Tuexen, M., Williams M., "Transport Layer 1939 Security (TLS) and Datagram Transport Layer Security (DTLS) 1940 Heartbeat Extension", RFC 6520, February 2012. 1942 8.2. Informative References 1944 [ASOKAN] Salowey, J., Hanna, S., "NEA Asokan Attack Analysis", 1945 draft-ietf-nea-asokan-00.txt (work in progress), April 1946 2012. 1948 [IFT-TLS] Trusted Computing Group, "TNC IF-T: Binding to TLS", 1949 http://www.trustedcomputinggroup.org/files/resource_files/5 1950 1F0757E-1D09-3519- 1951 AD63B6FD099658A6/TNC_IFT_TLS_v1_0_r16.pdf, May 2009. 1953 [PT-EAP] Cam-Winget, N., S., Sangster, P., "PT-EAP: Posture 1954 Transport (PT) Protocol For EAP Tunnel Methods", draft- 1955 ietf-nea-pt-eap-01.txt (work in progress), March 2012. 1957 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 1958 Tardo, "Network Endpoint Assessment (NEA): Overview and 1959 Requirements", RFC 5209, June 2008. 1961 [RFC5801] Josefsson, S., Williams, N., "Using Generic Security 1962 Service Application Program Interface (GSS-API) Mechanisms 1963 in Simple Authentication and Security Layer (SASL): The GS2 1964 Mechanism Family", RFC 5801, July 2010. 1966 Authors' Addresses 1968 Paul Sangster 1969 Symantec Corporation 1970 6825 Citrine Dr 1971 Carlsbad, CA 92009 1973 Email: paul_sangster@symantec.com 1975 Nancy Cam-Winget 1976 Cisco Systems 1977 80 West Tasman Drive 1978 San Jose, CA 95134 1979 US 1981 Email: ncamwing@cisco.com 1983 Joseph Salowey 1984 Cisco Systems 1985 2901 Third Avenue 1986 Seattle, WA 98121 1987 US 1989 Email: jsalowey@cisco.com