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