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