Internet Engineering Task Force (IETF) P. Sangster Request for Comments: 6876 Symantec Corporation Category: Standards Track N. Cam-Winget ISSN: 2070-1721 J. Salowey Cisco Systems February 2013 A Posture Transport Protocol over TLS (PT-TLS)
AbstractThis document specifies PT-TLS, a TLS-based Posture Transport (PT) protocol. The PT-TLS protocol carries the Network Endpoint Assessment (NEA) message exchange under the protection of a Transport Layer Security (TLS) secured tunnel. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6876. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1. Introduction ....................................................3 1.1. Prerequisites ..............................................4 1.2. Message Diagram Conventions ................................4 1.3. Conventions Used in This Document ..........................4 1.4. Compatibility with Other Specifications ....................4 2. Design Considerations ...........................................5 2.1. Benefits of TCP/IP Connectivity ............................5 2.2. Leveraging Proven TLS Security .............................6 2.3. TLV-Based Message Encapsulation ............................6 2.4. No Change to Base TLS Protocol .............................6 3. PT-TLS Protocol .................................................7 3.1. Initiating a PT-TLS Session ................................8 3.1.1. Issues with Server-Initiated PT-TLS Sessions ........8 3.1.2. Establish or Re-Use Existing PT-TLS Session .........9 3.2. TCP Port Usage .............................................9 3.3. Preventing MITM Attacks with Channel Bindings ..............9 3.4. PT-TLS Message Flow .......................................10 3.4.1. Assessment Triggers ................................10 3.4.2. PT-TLS Message Exchange Phases .....................11 126.96.36.199. TLS Setup Phase ...........................12 188.8.131.52. PT-TLS Negotiation Phase ..................13 184.108.40.206. PT-TLS Data Transport Phase ...............14 3.4.3. TLS Requirements ...................................14 3.5. PT-TLS Message Format .....................................15 3.6. IETF Namespace PT-TLS Message Types .......................18 3.7. PT-TLS Version Negotiation ................................20 3.7.1. Version Request Message ............................21 3.7.2. Version Response Message ...........................22 3.8. Client Authentication Using SASL ..........................22 3.8.1. SASL Client Authentication Requirements ............23 3.8.2. SASL in PT-TLS Overview ............................24 3.8.3. SASL Authentication Flow ...........................24 3.8.4. Aborting SASL Authentication .......................25 3.8.5. Linkages to SASL Framework .........................25 220.127.116.11. SASL Service Name .........................25 18.104.22.168. SASL Authorization Identity ...............25 22.214.171.124. SASL Security Layer .......................25 126.96.36.199. Multiple Authentications ..................25 3.8.6. SASL Channel Bindings ..............................25 3.8.7. SASL Mechanisms ....................................26 3.8.8. SASL Mechanism Selection ...........................26 3.8.9. SASL Authentication Data ...........................27 3.8.10. SASL Result .......................................28 3.9. Error Message .............................................29
4. Security Considerations ........................................32 4.1. Trust Relationships .......................................32 4.1.1. Posture Transport Client ...........................33 4.1.2. Posture Transport Server ...........................34 4.2. Security Threats and Countermeasures ......................35 4.2.1. Message Theft ......................................35 4.2.2. Message Fabrication ................................36 4.2.3. Message Modification ...............................36 4.2.4. Denial of Service ..................................37 4.2.5. NEA Asokan Attacks .................................37 4.2.6. Trust Anchors ......................................38 5. Privacy Considerations .........................................38 6. IANA Considerations ............................................38 6.1. Designated Expert Guidelines ..............................39 6.2. Registry for PT-TLS Message Types .........................40 6.3. Registry for PT-TLS Error Codes ...........................41 7. Acknowledgments ................................................41 8. References .....................................................42 8.1. Normative References ......................................42 8.2. Informative References ....................................43 RFC5209] defines a system for communicating posture between a client, where it is collected, and server, where it is assessed. Posture is configuration and/or status of hardware or software on an endpoint as it pertains to an organization's security policy. This document specifies PT-TLS, a TLS-based Posture Transport (PT) protocol protected by a TLS channel. NEA protocols are intended to be used for pre-admission assessment of endpoints joining the network and to assess endpoints already present on the network. In order to support both usage models, two different types (or bindings) of PT protocols are necessary to operate before and after the endpoint has an assigned IP address and other network- layer information. This specification focuses on the PT protocol used to assess endpoints already present on the network and thus is able to use TCP/IP-based transport protocols. NEA has defined another protocol called PT-EAP [PT-EAP] to address assessment prior to the endpoint having an assigned IP address. The Posture Transport protocol in the NEA architecture [RFC5209] is responsible for transporting Posture Broker (PB-TNC [RFC5793]) batches, often containing Posture Attributes (PA-TNC [RFC5792]) over the network between the Posture Transport Client component of the NEA Client and the Posture Transport Server component of the NEA Server.
The PT protocol also offers strong security protections to ensure that the exchanged messages are protected from a variety of threats from hostile intermediaries. RFC5209]. The reader is assumed to be thoroughly familiar with [RFC5209]. The NEA working group compared the functionality described in this specification with the requirements in [RFC5209] and found that each applicable requirement was addressed. RFC2119].
o Large Messages - ability to send very large Posture Attribute messages without directly fragmenting them (underlying carrier protocol may introduce fragmentation) o Bidirectional - NEA Client and NEA Server can initiate an assessment or reassessment o Multiple Roundtrips - NEA Client and NEA Server can exchange numerous messages without fear of infrastructure timeouts. However, the entire exchange should be kept as brief as possible if the user has to wait for its completion. RFC5246] to secure the connection. TLS was selected because it's a widely deployed protocol with parallel protections to a number of the EAP tunnel methods, and it meets all of the security requirements.
ChangeCipherSpec phase, allowing the PT message to be protected. The benefit of this approach is that the assessment protocol could operate below the application protocols, allowing for easier integration into applications. However, making this change would require some extensions to the TLS handshake protocol standards and existing widely deployed TLS implementations, so it wasn't clear that the cost was warranted, particularly because the application independence can also be offered by a shim library between the application and TLS library that provides the PT protocol encapsulation/decapsulation. The other general approach considered was to have PT-TLS layer on top of TLS as an application protocol (using the standard application_data ContentType). This has the advantage that existing TLS software could be used. However, the PB-TNC traffic would need to be encapsulated/decapsulated by a new PT-TLS protocol layer before being passed to the TLS library. This didn't seem like a significant issue, as PB-TNC is architected to layer on PT anyway. After considering the different options, it was determined that layering the PT protocol on top of the TLS protocol without requiring current TLS protocol implementations to change met all the requirements and offered the best path toward rapid adoption and deployment. Therefore, the following sections describe a PT protocol that is carried on top of TLS. Figure 1, this protocol runs directly on top of TLS as an application. This means PT-TLS is encapsulated within the TLS Record Layer protocol using the standard ContentType for applications (application_data). +---------------------------------------------------------------+ | TLV Encapsulation of PB-PA message | +---------------------------------------------------------------+ | TLS | +---------------------------------------------------------------+ | TCP | +---------------------------------------------------------------+ Figure 1. PT-TLS Layering Model
addition, each side needs to be able to authorize its peer based upon matching Subject and SubjectAltName fields for certificates issued by a particular trust anchor. Therefore, NEA Clients SHOULD be capable of establishing and holding open a TLS session with the NEA Server immediately after obtaining network access. A NEA Client MAY listen for connection requests from the NEA Server and establish a new PT-TLS session when one does not already exist. Because of the potential added complexity, a NEA Client's support for accepting inbound PT-TLS connections is optional to implement. Having an existing PT-TLS session allows either party to initiate an assessment without requiring the NEA Client to be listening for new connection requests. In order to keep the TLS session alive, the NEA Client and NEA Server SHOULD be capable of supporting the TLS heartbeat protocol [RFC6520]. RFC6813], a sophisticated Man-in-the-Middle (MITM) attack can be mounted against NEA systems. The attacker forwards PA-TNC messages from a healthy machine through an unhealthy one so that the unhealthy machine can gain network access. Because there are easier attacks on NEA systems, like having the unhealthy machine lie about its configuration, this attack is generally only mounted against machines with an External Measurement Agent (EMA). The EMA is a separate entity, difficult to compromise, that measures and attests to the configuration of the endpoint.
To protect against NEA Asokan attacks, the Posture Broker Client on an EMA-equipped endpoint should pass the tls-unique channel binding [RFC5929] for PT-TLS's underlying TLS session to the EMA. This value can then be included in the EMA's attestation, and the Posture Validator responsible for communicating with the EMA may then confirm that the value matches the tls-unique channel binding for its end of the connection. If the values match, the posture sent by the EMA and NEA Client is from the same endpoint as the client side of the TLS connection (since the endpoint knows the tls-unique value), so no man-in-the-middle is forwarding posture. If they differ, the Asokan attack has been detected. The Posture Validator MUST fail its verification of the endpoint if the Asokan attack has been detected.
Section 3.1, the TCP connection establishment and/or the TLS handshake protocol could be initiated by either the NEA Client or NEA Server. The most common situation would be for the assessment initiator to trigger the creation of the TCP connection and TLS handshake, so an assessment could begin when no session already exists. When the NEA Server has initiated the TLS Setup, the NEA Server is acting as a TLS client and the NEA Client is the TLS server (accepting the inbound TLS session request). The expected normal case is that the NEA Client initiates this phase, so that the NEA Server is acting as the TLS server and therefore the bootstrapping of the security of the TLS session is using the NEA Server's certificate. Having the NEA Client initiate the TLS session avoids the need for the NEA Client to also possess a certificate. During the TLS Setup phase of PT-TLS, the PT-TLS Initiator contacts the listening port of the PT-TLS Responder and performs a TLS handshake. The PT-TLS Responder MUST possess a trustworthy X.509 certificate used to authenticate to the PT-TLS Initiator and used to bootstrap the security protections of the TLS session. The PT-TLS Initiator MAY also use an X.509 certificate to authenticate to the PT-TLS Responder providing for a bidirectional authentication of the PT-TLS session. The NEA Client MUST provide certificate validation according to the rules in RFC 5280 when evaluating the server certificate. The NEA Client MAY perform certificate revocation checking on the NEA Server's certificate. This specification allows the NEA Client implementation to decide on what certificate revocation technique is to be implemented. If revocation information is not provided in a TLS handshake extension, then clients performing certificate validation will require some network access (e.g., HTTP) to be allowed during the assessment. NEA Client network access to other non-essential services might be restricted during assessments in some situations. If the client cannot access the status information, then its policy may prevent it from completing the TLS handshake.
In addition, the NEA Client MUST follow the recommendations in RFC 6125 [RFC6125] when validating the NEA Server domain name against the contents of the server certificate, taking into consideration the following restrictions: o Any SRV-IDs and URI-IDs in the certificate are ignored. o Use of CN-IDs in certificates is NOT RECOMMENDED. o Wildcards MUST NOT appear in the DNS-ID or CN-ID of a certificate identifying a PT-TLS server. Details for the reverse direction are given in Section 3.1. Due to deployment issues with issuing and distributing certificates to a potentially large number of NEA Clients, this specification allows the NEA Client to be authenticated during the PT-TLS Negotiation phase using other more cost-effective methods, as described in Section 3.8.1. At the conclusion of a successful initial TLS Setup phase, the NEA Client and NEA Server have a protected session to exchange messages. This allows the protocol to transition to the PT-TLS Negotiation phase. Section 3.8. The NEA Server initiates the client authentication and indicates when the authentication is complete. When the NEA Client receives the Simple Authentication and Security Layer (SASL) [RFC4422] Mechanisms list, the NEA Client responds with a SASL Mechanism Selection TLV indicating the method of authentication to be used. Upon selecting an appropriate SASL
mechanism, the NEA Client and Server exchange SASL-mechanism-specific messages in order to authenticate the NEA Client. When the client authentication successfully completes and no additional authentications are required (as indicated by the NEA Server sending an empty SASL Mechanisms list), the PT-TLS session transitions into the Data Transport phase, where it will remain for the duration of the session. Note that the NEA Server could choose to not authenticate the client (indicated by only sending an empty SASL Mechanisms list) or to continue performing a posture assessment even if the authentication did not complete successfully.
deployment and known security vulnerabilities. At the time of this writing, TLS version 1.2 [RFC5246] is the most recent version, but it has a very limited deployment base and might not be readily available for implementation. TLS version 1.0 [RFC2246] and version 1.1 [RFC4346] are the most widely deployed versions and will provide the broadest interoperability. Implementations of PT-TLS SHOULD support use of TLS 1.2. For each TLS version supported, implementations of the PT-TLS protocol MUST at least support the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite. This cipher suite requires the server to provide a certificate that can be used during the key exchange. Implementations SHOULD NOT include support for cipher suites that do not minimally offer PT-TLS Responder (typically Posture Transport Server) authentication, such as the anonymous Diffie-Hellman cipher suites (e.g., TLS_DH_anon_WITH_AES_128_CBC_SHA). Implementations MUST support RFC 5746 [RFC5746]. Implementations MAY allow renegotiation to provide confidentiality for the client certificate. If renegotiation is allowed, implementations need to select the appropriate handshake messages as described in RFC 5929 for the tls-unique value.
Message Type Vendor ID This field indicates the owner of the namespace associated with the message type. This is accomplished by specifying the 24-bit Structure of Management Information (SMI) Private Enterprise Number [PEN] (Vendor ID) of the party who owns the message type namespace. Consistent with PA-TNC and PB-TNC, we depend on the PEN fitting in 24 bits, so if IANA were to register a wider PEN, then that PEN could not be used with NEA. IETF namespace PT-TLS Message Types MUST use zero (0) in this field. For more information about the intended use of NEA namespace identifiers, see the PA-TNC specification (RFC 5792), Sections 2.1 and 2.2. The PT-TLS Message Type Vendor ID 0xffffff is reserved. Posture Transport Clients and Servers MUST NOT send PT-TLS messages in which the PT-TLS Message Type Vendor ID has this reserved value (0xffffff). If a Posture Transport Client or Posture Transport Server receives a message containing this reserved value (0xffffff) in the PT-TLS Message Type Vendor ID, the recipient SHOULD respond with an Invalid Parameter error code in a PT-TLS Error message. Message Type This field defines the type of the PT-TLS message within the scope of the specified Message Type Vendor ID that is included in the Message Value field. The specific IETF-defined values allowable in this field when the Message Type Vendor ID is the IETF SMI Private Enterprise Number value (0) are defined in Section 3.6. Recipients of a message containing a Message Type Vendor ID and a message type that is unrecognized SHOULD respond with a Type Not Supported error code in a PT-TLS Error message. Posture Transport Clients and Posture Transport Servers MUST NOT require support for particular vendor-defined PT-TLS Message Types in order to interoperate with other PT-TLS compliant implementations (although implementations MAY permit administrators to configure them to require support for specific vendor-defined PT-TLS Message Types). If the PT-TLS Message Type Vendor ID field has the value zero (0), then the PT-TLS Message Type field contains an IETF namespace PT-TLS Message Type, as listed in the IANA registry. IANA maintains a registry of PT-TLS Message Types. Entries in this registry are added following the IANA Specification Required policy, following the guidelines in Section 6.1. Section 3.6 of this specification defines the initial set of IETF-defined PT-TLS Message Types.
The PT-TLS Message Type 0xffffffff is reserved. Posture Transport Clients and Posture Transport Servers MUST NOT send PT-TLS messages in which the PT-TLS Message Type has this reserved value (0xffffffff). If a Posture Transport Client or Posture Transport Server receives a message in which the PT-TLS Message Type has this reserved value (0xffffffff), it SHOULD respond with an Invalid Parameter error code in a PT-TLS Error message. Message Length This field contains the length in octets of the entire PT-TLS message (including the entire header). Therefore, this value MUST always be at least 16. Any Posture Transport Client or Posture Transport Server that receives a message with a PT-TLS Message Length field whose value is less than 16 SHOULD respond with an Invalid Parameter PT-TLS Error Code. Similarly, if a Posture Transport Client or Posture Transport Server receives a PT-TLS message for a Message Type that has a known Message Length and the Message Length indicates a different value (greater or less than the expected value), the recipient SHOULD respond with an Invalid Parameter PT-TLS Error Code. Message Identifier This field contains a value that uniquely identifies the PT-TLS message on a per message sender (Posture Transport Client or Server) basis. This value is copied into the body of the PT-TLS Error message so the recipient can determine which message caused the error. The Message Identifier MUST be a monotonically increasing counter starting at zero indicating the number of the messages the sender has transmitted over the TLS session. It is possible that a busy or long-lived session might exceed 2^32-1 messages sent, so the message sender MUST roll over to zero upon reaching the 2^32nd message, thus restarting the increasing counter. During a rollover, it is feasible that the message recipient could be confused if it keeps track of every previously received Message Identifier, so recipients MUST be able to handle rollover situations without generating errors.
Message Value The contents of this field vary depending on the particular Message Type Vendor ID and Message Type given in the PT-TLS header for this PT-TLS message. This field most frequently contains a PB-TNC batch. The contents of this field for each of the initial IETF namespace PT-TLS Message Types are defined in this specification.
2 (Version Response) PT-TLS protocol version selected by the responder. This message type MUST only be sent by the PT-TLS Responder as the second message in the PT-TLS Negotiation phase. Recipients MUST send an Invalid Message error code in a PT-TLS Error message if a Version Response is received at another time. 3 (SASL Mechanisms) Sent by the NEA Server to indicate what SASL mechanisms it is willing to use for authentication on this session. This message type MUST only be sent by the NEA Server in the PT-TLS Negotiation phase. The NEA Client MUST send an Invalid Message error code in a PT-TLS Error message if a SASL Mechanisms message is received at another time. 4 (SASL Mechanism Selection) Sent by the NEA Client to select a SASL mechanism from the list offered by the NEA Server. This message type MUST only be sent by the NEA Client in the PT-TLS Negotiation phase. The NEA Server MUST send an Invalid Message error code in a PT-TLS Error message if a SASL Mechanism Selection is received after the PT-TLS Negotiation phase. Once a SASL mechanism has been selected, it may not change until the mechanism completes either successfully or as a failure. 5 (SASL Authentication Data) Opaque octets exchanged between the NEA Client and NEA Server's SASL mechanisms to perform the client authentication. This message type MUST only be sent during the PT-TLS Negotiation phase. Recipients MUST send an Invalid Message error code in a PT-TLS Error message if a SASL Authentication Data message is received after the PT-TLS Negotiation phase.
6 (SASL Result) Indicates the result code of the SASL mechanism authentication as described in Section 3.8.10. This message type MUST only be sent by the NEA Server when the NEA Client and NEA Server are in the PT-TLS Negotiation phase. The NEA Client MUST send an Invalid Message error code in a PT-TLS Error message if a SASL Result is received after the PT-TLS Negotiation phase. 7 (PB-TNC Batch) Contains a PB-TNC batch. For more information on PB-TNC batches, see RFC 5793 (PB-TNC) Section 4. This message type MUST only be sent when the NEA Client and NEA Server are in the PT-TLS Data Transport phase. Recipients SHOULD send an Invalid Message error code in a PT-TLS Error message if a PB-TNC Batch is received outside of the Data Transport phase. 8 (PT-TLS Error) PT-TLS Error message as described in Section 3.9. This message type may be used during any PT-TLS phase. 9-4294967294 (Unassigned) These values are for future allocation following guidelines defined in the IANA Considerations section (see Section 6.1). Recipients of unsupported messages in the IETF namespace using a message type of 9 to 4294967294 MUST respond with a Type Not Supported PT-TLS Error Code in a PT-TLS Error message. 4294967295 Reserved
reception of any additional messages. After the successful completion of the version negotiation, both the Posture Transport Client and Posture Transport Server MUST only send messages compliant with the negotiated protocol version. Subsequent assessments on the same session MUST use the negotiated version number and therefore MUST NOT send additional version negotiation messages.
Pref Vers This field contains the sender's preferred version of the PT-TLS protocol. This is a hint to the recipient that the sender would like this version selected if supported. The value of this field MUST fall within the range of Min Vers to Max Vers. This field MUST be set to 1 indicating support for the first version of PT-TLS. However, future versions of this specification will probably remove this requirement, so PT-TLS Responders MUST be prepared to receive other values.
for performing an authentication of the client using PT-TLS messages is to integrate the Simple Authentication and Security Layer (SASL) [RFC4422] framework. SASL provides a number of standards-based authentication mechanisms capable of authenticating the NEA Client using a variety of base technologies. Client authentication could occur during the TLS handshake using TLS- defined authentication techniques. Because this client authentication is optional, the NEA Server's policy might require the client to be authenticated by PT-TLS before performing the assessment. Similarly, the NEA Server may require a PT-TLS authentication even if the NEA Client was authenticated during the TLS handshake (e.g., to allow a user authentication after a system- level authentication occurred during the TLS handshake). The decision of whether a SASL client authentication is to occur is left to the NEA Server's policy. As discussed in Section 3.1.1, it is possible that the NEA Server may initiate the TLS session to the NEA Client, thus causing it to fill the role of TLS client during the TLS handshake. Because the NEA Server is required to possess an X.509 certificate for those times when it is acting as the TLS server (normal case), PT-TLS requires that the NEA Server MUST use its X.509 certificate for TLS client authentication during the TLS handshake to authenticate itself even when it is acting as the TLS client. In this case, the NEA Client and NEA Server will authenticate using certificates during the TLS handshake, so the PT-TLS SASL client authentication might not be required unless NEA Server policy required an additional authentication of the NEA Client. Therefore, the normal usage for the SASL messages is when the NEA Client acted as the TLS client and did not authenticate during the TLS handshake. RFC4616]. Similarly, implementations MUST provide the EXTERNAL SASL mechanism if both parties are authenticated during the TLS establishment. In order to be able to take advantage of other strong, widely deployed authentication technologies such as Kerberos and support for channel bindings, implementations MAY
include support for GS2 (the second Generic Security Service Application Program Interface (GSS-API) bridge for SASL) [RFC5801]. GS2 includes negotiable support for channel binding for use with SASL (see Section 5 of RFC 5801). Implementations MUST also support the case where no client authentication is required.
a SASL Mechanisms TLV with no mechanisms as the last message in the PT-TLS Negotiation phase, and the NEA Client MUST NOT transition to the PT-TLS Data Transport phase until it receives such a message. If the NEA Server receives a NEA assessment message before the completion of the client authentication, the NEA Server MUST send an Authentication Required PT-TLS Error message indicating to the NEA Client that an authentication exchange is required prior to entering the PT-TLS Data Transport phase. RFC 4422. RFC 5929 is carried by the SASL mechanism. For most mechanisms, this means including the
Rsvd (Reserved) Reserved for future use. This field MUST be set to 0 on transmission and ignored upon reception. Mech Len (Mechanism Name Length) The length of the Mechanism Name field in octets. Mechanism Name SASL mechanism name adhering to the rules defined in RFC 4422. Optional Initial Mechanism Response Initial set of authentication information required from the NEA Client to kick-start the authentication. This data is optional and if not provided would be solicited by the NEA Server in the first SASL Authentication Data TLV request.
Optional Result Data This field contains a variable-length set of additional data for a successful result. This field MUST be zero length unless the NEA Server is returning a Result Code of Success and has more data to return. For more information on the additional data with success in SASL, see RFC 4422.
Error Code Vendor ID This field contains the IANA-assigned SMI Private Enterprise Number for the vendor whose Error Code namespace is being used in the message. For IETF namespace Error Code values, this field MUST be set to zero (0). For other vendor-defined Error Code namespaces, this field MUST be set to the SMI Private Enterprise Number of the vendor. Error Code This field contains the error code. This error code exists within the scope of Error Code Vendor ID in this message. Posture Transport Clients and Posture Transport Servers MUST NOT require support for particular vendor-specific PT-TLS Error Codes in order to interoperate with other PT-TLS-compliant implementations (although implementations MAY permit administrators to configure them to require support for specific PT-TLS Error Codes). When the Error Code Vendor ID is set to the IETF Private Enterprise Number, the following table lists the initial supported IETF-defined numeric error codes: Value (Name) Definition ------------------------- --------------------------------------- 0 (Reserved) Reserved value indicates that the PT-TLS Error message SHOULD be ignored by all recipients. This MAY be used for debugging purposes to allow a sender to see a copy of the message that was received. 1 (Malformed Message) PT-TLS message unrecognized or unsupported. This error code SHOULD be sent when the basic message content sanity test fails. The sender of this error code MUST consider it a fatal error and abort the assessment. 2 (Version Not Supported) This error SHOULD be sent when a PT-TLS Responder receives a PT-TLS Version Request message containing a range of version numbers that doesn't include any version numbers that the recipient is willing and able to support on the session. All PT-TLS messages carrying the Version Not Supported error code MUST use a version number of 1. All
parties that receive or send PT-TLS messages MUST be able to properly process an error message that meets this description, even if they cannot process any other aspect of PT-TLS version 1. The sender and receiver of this error code MUST consider it a fatal error and close the TLS session after sending or receiving this PT-TLS message. 3 (Type Not Supported) PT-TLS Message Type unknown or not supported. When a recipient receives a PT-TLS Message Type that it does not support, it MUST send back this error, ignore the message, and proceed. For example, this could occur if the sender used a Vendor ID for the Message Type that is not supported by the recipient. This error message does not indicate that a fatal error has occurred, so the assessment is allowed to continue. 4 (Invalid Message) PT-TLS message received was invalid based on the protocol state. For example, this error would be sent if a recipient receives a message associated with the PT-TLS Negotiation Phase (such as Version messages) after the protocol has reached the PT-TLS Data Transport Phase. The sender and receiver of this error code MUST consider it a fatal error and close the TLS session after sending or receiving this PT-TLS message. 5 (SASL Mechanism Error) A fatal error occurred while trying to perform the client authentication. For example, the NEA Client is unable to support any of the offered SASL mechanisms. The sender and receiver of this error code MUST consider it a fatal error and close the TLS session after sending or receiving this PT-TLS message.
6 (Invalid Parameter) The PT-TLS Error message sender has received a message with an invalid or unsupported value in the PT-TLS header. This could occur if the NEA Client receives a PT-TLS message from the NEA Server with a Message Length of zero (see Section 3.5 for details). The sender and receiver of this error code MUST consider it a fatal error and close the TLS session after sending or receiving this PT-TLS message. Copy of Original Message This variable-length value MUST contain a copy (up to 1024 bytes) of the original PT-TLS message that caused the error. If the original message is longer than 1024 bytes, only the initial 1024 bytes will be included in this field. This field is included so the error recipient can determine which message sent caused the error. In particular, the recipient can use the Message Identifier field from the Copy of Original Message data to determine which message caused the error.
o Verify the security protections placed upon messages received from the network to ensure that the messages are authentic and protected from attacks on the network
o Not ignore or drop messages when such an action would cause issues for the protocol processing (e.g., dropping PT-TLS SASL Result messages) o Verify the security protections placed upon messages received from the network to ensure that the messages are authentic and protected from attacks on the network Section 4.1, the PT-TLS protocol faces a number of potential security attacks that could require security countermeasures. Generally, the PT-TLS protocol is responsible for offering strong security protections for all of the NEA protocols, so any threats to its ability to protect NEA protocol messages could be very damaging to deployments. Once the message is delivered to the Posture Broker Client or Posture Broker Server, the posture brokers are trusted to properly and safely process the messages.
assessment dialog. The PT-TLS protocol also provides strong cryptography for all of the PB-TNC and PA-TNC protocol messages traveling over the network, allowing the message contents to be hidden from potential theft by the adversary even if the attacker is able to observe the encrypted PT-TLS session.
Section 3.3 and in [RFC6813], a sophisticated MITM attack can be mounted against NEA systems. The attacker forwards PA-TNC messages from a healthy machine through an unhealthy one so that the unhealthy machine can gain network access. Section 3.3 and [RFC6813] provide a detailed description of this attack and of the countermeasures that can be employed against it. Because lying endpoint attacks are much easier than Asokan attacks and the only known effective countermeasure against lying endpoint attacks is the use of an External Measurement Agent (EMA), countermeasures against an Asokan attack are not necessary unless an EMA is in use. However, PT-TLS implementers may not know whether an EMA will be used with their implementation. Therefore, PT-TLS implementers SHOULD support the Asokan attack countermeasures described in Section 3.3 by providing the value of the tls-unique channel binding to higher layers in the NEA reference model: Posture Broker Clients, Posture Broker Servers, Posture Collectors, and Posture Validators. The Asokan attack can also apply to authentication mechanisms carried within TLS. SASL mechanisms providing channel bindings use the tls-unique channel-binding data as defined in Section 3.3 to protect against the attack.
This section defines the contents of two new IANA registries, PT-TLS Message Types and PT-TLS Error Codes, and explains how these registries work. Each of the registries defined in this document support IETF-defined values and vendor-defined values. To explain this phenomenon, we will use the PT-TLS Message Type as an example, but the other registry works the same way. Whenever a PT-TLS Message Type appears on a network, it is always accompanied by an SMI Private Enterprise Number (PEN), also known as a vendor ID. If this vendor ID is zero, the accompanying PT-TLS Message Type is an IETF namespace value listed in the IANA registry for PT-TLS Message Types, and its meaning is defined in the specification listed for that PT-TLS Message Type in that registry. If the vendor ID is not zero, the meaning of the PT-TLS Message Type is defined by the vendor identified by the vendor ID (as listed in the IANA registry for SMI PENs). The identified vendor is encouraged but not required to register with IANA some or all of the PT-TLS Message Types used with their vendor ID and publish a specification for each of these values. RFC5226]. This section provides guidance to designated experts so that they may make decisions using a philosophy appropriate for these registries. The registries defined in this document have plenty of values. In most cases, the IETF has approximately 2^32 values available for it to define, and each vendor has the same number of values for its use. Because there are so many values available, designated experts should not be terribly concerned about exhausting the set of values. Instead, designated experts should focus on the following requirements. All values in these IANA registries are required to be documented in a specification that is permanently and publicly available. IETF namespace values must also be useful not harmful to the Internet, and defined in a manner that is clear and likely to ensure interoperability. Designated experts should encourage vendors to avoid defining similar but incompatible values and instead agree on a single IETF-reviewed approach and value. However, it is beneficial to document existing practice.
There are several ways to ensure that a specification is permanently and publicly available. It may be published as an RFC. Alternatively, it may be published in another manner that makes it freely available to anyone. However, in this latter case, the vendor will need to supply a copy to the IANA and authorize the IANA to archive this copy and make it freely available to all if at some point the document becomes no longer freely available to all through other channels. The following two sections provide guidance to the IANA in creating and managing the new IANA registries defined by this specification. Section 6.1. PEN Value Name Reference --- -------- ------------------------ --------- 0 0 Experimental RFC 6876 0 1 Version Request RFC 6876 0 2 Version Response RFC 6876 0 3 SASL Mechanisms RFC 6876 0 4 SASL Mechanism Selection RFC 6876 0 5 SASL Authentication Data RFC 6876 0 6 SASL Result RFC 6876 0 7 PB-TNC Batch RFC 6876 0 8 PT-TLS Error RFC 6876 0 9-4294967294 Unassigned 0 4294967295 Reserved RFC 6876 The PEN 0 (IETF) PT-TLS Message Type values between 9 and 4294967294 inclusive are allocated for future assignment by the IANA.
Section 6.1. PEN Value Name Reference --- ------------ --------------------- --------- 0 0 Reserved RFC 6876 0 1 Malformed Message RFC 6876 0 2 Version Not Supported RFC 6876 0 3 Type Not Supported RFC 6876 0 4 Invalid Message RFC 6876 0 5 SASL Mechanism Error RFC 6876 0 6 Invalid Parameter RFC 6876 0 7-4294967295 Unassigned The PEN 0 (IETF) PT-TLS Error Codes between 7 and 4294967295 inclusive are allocated for future assignment by the IANA. IFT-TLS]. The authors of this document would also like to acknowledge the following people who have contributed to or provided substantial input on the preparation of this document or predecessors to it: Syam Appala, Stuart Bailey, Lauren Giroux, Steve Hanna, Josh Howlett, Scott Kelly, Carolin Latze, Sung Lee, Lisa Lorenzin, Alexey Melnikov, Ravi Sahita, Subbu Srinivasan, Susan Thomson, and Mark Townsend.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006. [RFC4616] Zeilenga, K., Ed., "The PLAIN Simple Authentication and Security Layer (SASL) Mechanism", RFC 4616, August 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, February 2010. [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5792, March 2010. [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5793, March 2010. [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, July 2010. [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, February 2012. [IFT-TLS] Trusted Computing Group, "TNC IF-T: Binding to TLS", <http://www.trustedcomputinggroup.org/>, May 2009. [PEN] IANA Private Enterprise Numbers (PEN) registry, <http://www.iana.org/assignments/enterprise-numbers>. [PT-EAP] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods", Work in Progress, January 2013. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, June 2008. [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family", RFC 5801, July 2010. [RFC6813] Salowey, J. and S. Hanna, "The Network Endpoint Assessment (NEA) Asokan Attack Analysis", RFC 6813, December 2012.