GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6876

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)

Abstract

 This 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.

Sangster, et al. Standards Track [Page 1] RFC 6876 PT-TLS February 2013

Table of Contents

 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
                3.4.2.1. TLS Setup Phase ...........................12
                3.4.2.2. PT-TLS Negotiation Phase ..................13
                3.4.2.3. 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
                3.8.5.1. SASL Service Name .........................25
                3.8.5.2. SASL Authorization Identity ...............25
                3.8.5.3. SASL Security Layer .......................25
                3.8.5.4. 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

Sangster, et al. Standards Track [Page 2] RFC 6876 PT-TLS February 2013

 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

1. Introduction

 The NEA architecture [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.

Sangster, et al. Standards Track [Page 3] RFC 6876 PT-TLS February 2013

 The PT protocol also offers strong security protections to ensure
 that the exchanged messages are protected from a variety of threats
 from hostile intermediaries.

1.1. Prerequisites

 This document does not define an architecture or reference model.
 Instead, it defines one binding of the PT protocol that works within
 the reference model described in the NEA Overview and Requirements
 specification [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.

1.2. Message Diagram Conventions

 This specification defines the syntax of PT-TLS messages using
 diagrams.  Each diagram depicts the format and size of each field in
 bits.  Implementations MUST send the bits in each diagram as they are
 shown, traversing the diagram from top to bottom and then from left
 to right within each line (which represents a 32-bit quantity).
 Multi-byte fields representing numeric values must be sent in network
 (big endian) byte order.
 Bit field (e.g., flag) values are described referring to the position
 of the bit within the field.  These bit positions are numbered from
 the most significant bit through the least significant bit, so a
 one-octet field with only bit 0 set has the value 0x80.

1.3. Conventions Used in This Document

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
 "OPTIONAL" in this document are to be interpreted as described in
 RFC 2119 [RFC2119].

1.4. Compatibility with Other Specifications

 One of the goals of the NEA effort is to deliver a single set of
 endpoint assessment standards, agreed upon by all parties.  For this
 reason, the authors understand that the Trusted Computing Group (TCG)
 will be replacing its existing posture transport protocols with new
 versions that are equivalent to and interoperable with the NEA
 specifications.

Sangster, et al. Standards Track [Page 4] RFC 6876 PT-TLS February 2013

2. Design Considerations

 This section discusses some of the key design considerations for the
 PT protocol.  This document specifies the PT binding for use when
 performing an assessment or reassessment after the endpoint has been
 admitted to the network and is capable of using TCP/IP to communicate
 with the NEA Server.  If the endpoint does not yet have TCP/IP-layer
 access to the NEA Server (and vice versa), the endpoint can use the
 PT-EAP (Posture Transport (PT) Protocol for Extensible Authentication
 Protocol (EAP) Tunnel Methods) protocol when performing an
 assessment.
 Because the endpoint has TCP/IP access to the NEA Server (potentially
 on a restricted portion of the network), the NEA Client and NEA
 Server have the ability to establish (or re-use) a reliable TCP/IP
 connection in order to perform the assessment.  The TCP/IP connection
 enables the assessment to occur over a relatively high-performance,
 reliable channel capable of supporting multiple roundtrip message
 exchanges in a full-duplex manner.  These connection properties are
 very different from what is available when the endpoint is initially
 joining the network (e.g., during an 802.1X-based assessment);
 therefore, the design described in this specification follows a
 different path to maximize the benefits of the underlying TCP/IP
 connection.

2.1. Benefits of TCP/IP Connectivity

 The PT protocol over TLS is typically able to offer to the NEA Client
 and NEA Server significantly higher quality of service and
 flexibility of operation than PT-EAP.  However, there may be some
 added risks when the endpoint is on the network prior to its initial
 assessment (if no admission time assessment had been performed).
 Because of these risks, the combined use of an EAP-based assessment
 during admission followed by reassessment using TCP/IP may be
 appropriate in some environments.
 Some of the benefits to having a TCP/IP-based transport during an
 assessment include:
 o  Full-Duplex Connectivity - used to support asynchronous initiation
    of posture exchanges within a single TLS connection (e.g.,
    triggered by alerts of posture or policy changes)
 o  High Bandwidth - potentially much higher bandwidth than other
    transports (e.g., EAP), allowing more in-band data (e.g.,
    remediation, verbose posture information)

Sangster, et al. Standards Track [Page 5] RFC 6876 PT-TLS February 2013

 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.

2.2. Leveraging Proven TLS Security

 All PT protocol bindings must be capable of providing strong
 authentication, integrity, and confidentiality protection for the
 PB-TNC batches.  Rather than define a new protocol over TCP/IP to
 provide adequate protection, this specification requires the use of
 Transport Layer Security [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.

2.3. TLV-Based Message Encapsulation

 The design of the PT-TLS protocol is based upon the use of a
 type-length-value (TLV)-oriented protocol message that identifies the
 type of message, the message's length, and a potentially variable-
 length payload value.  The use of a TLV-oriented encoding was chosen
 to match the Internet standard PA-TNC and PB-TNC protocols.  Because
 the PA-TNC, PB-TNC, and PT-TLS protocols are typically implemented
 inside the same process space, this allows a common set of message-
 parsing code to be used.  Similarly, creation of debugging tools is
 simplified by the common encoding methodologies.  TLV-based encoding
 was used in each of the NEA protocols in part because it enables a
 very space-efficient representation on the network and is simpler to
 parse than some other encodings to benefit lower-powered (or battery
 constrained) devices.

2.4. No Change to Base TLS Protocol

 During the design of the PT-TLS protocol, several approaches were
 considered with different costs and benefits.  Several considered
 approaches involved integrating the PT protocol into the TLS
 handshake protocol.  Because the PT protocol requires the underlying
 TLS carrier to provide security protections, the PT protocol couldn't
 operate before the cipher suites were negotiated and in use.  One
 option was to integrate into the TLS handshake protocol after the

Sangster, et al. Standards Track [Page 6] RFC 6876 PT-TLS February 2013

 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.

3. PT-TLS Protocol

 This section specifies the PT-TLS protocol, a Posture Transport (PT)
 protocol carried by the Transport Layer Security (TLS) protocol over
 a TCP/IP network.  As shown in 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

Sangster, et al. Standards Track [Page 7] RFC 6876 PT-TLS February 2013

3.1. Initiating a PT-TLS Session

 The PT-TLS protocol may be initiated by a Posture Transport Client or
 a Posture Transport Server.  This flexibility supports different use
 cases.  For example, a Posture Transport Client that wishes to
 trigger a NEA assessment to determine whether its security posture is
 good can start up a PT-TLS session and request a posture assessment.
 On the other hand, when an endpoint requests access to a protected
 network or resource, a Posture Transport Server can start up a PT-TLS
 session and perform a posture assessment before deciding whether to
 grant access.
 The party that initiates a PT-TLS session is known as the "PT-TLS
 Initiator".  The other party in the session (which receives the
 request to open a PT-TLS session) is known as the "PT-TLS Responder".

3.1.1. Issues with Server-Initiated PT-TLS Sessions

 In order for a NEA Server to establish a PT-TLS session, the NEA
 Client needs to be listening for a connection request on a TCP port
 known by the NEA Server.  In many deployments, the security policies
 of an endpoint (e.g., firewall software) or the security policies of
 a network (e.g., firewall devices) are designed to minimize the
 number of open inbound TCP/UDP ports that are available to the
 network to reduce the potential attack footprint.  This is one issue
 that makes it difficult for a NEA Server to initiate a PT-TLS
 session.
 Another issue with this scenario involves X.509 certificates.  When
 the NEA Server creates a TLS session to the NEA Client, the NEA
 Client is effectively acting as the TLS server during the TLS
 protocol exchange.  This means the NEA Client would typically need to
 possess an X.509 certificate to protect the initial portion of the
 TLS handshake.  In situations where the NEA Server initiates the
 creation of the TLS session, both the NEA Client and NEA Server MUST
 possess X.509 certificates to fully authenticate the session.  For
 many deployments, provisioning X.509 certificates to all NEA Clients
 has scalability and cost issues; therefore, it is recommended that
 the NEA Client not listen for connection requests from the NEA Server
 but instead establish and maintain a TLS session to the NEA Server
 proactively, so either party can initiate an assessment using the
 preexisting TLS session as required.
 In most cases, the traditional methods of server certificate ID
 validation will not apply when the NEA Server initiates the
 connection.  In this case, the NEA Client and Server need to follow
 the certificate path validation rules in RFC 5280 [RFC5280].  In

Sangster, et al. Standards Track [Page 8] RFC 6876 PT-TLS February 2013

 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].

3.1.2. Establish or Re-Use Existing PT-TLS Session

 A single PT-TLS session can support multiple NEA assessments, which
 can be started by either party (the PT-TLS Initiator or the PT-TLS
 Responder).  The party that starts a NEA assessment is known as the
 "assessment initiator", and the other party is known as the
 "assessment responder".
 If the assessment initiator already has a PT-TLS session to the
 assessment responder, the initiator can re-use this session;
 otherwise, a new PT-TLS session needs to be established.

3.2. TCP Port Usage

 In order for a PT-TLS Initiator to establish a TCP connection to a
 PT-TLS Responder, the initiator needs to know the TCP port number on
 which the responder is listening for assessment requests.  The IANA
 has reserved TCP port number 271 for use by "pt-tls".

3.3. Preventing MITM Attacks with Channel Bindings

 As described in "The Network Endpoint Assessment (NEA) Asokan Attack
 Analysis" [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.

Sangster, et al. Standards Track [Page 9] RFC 6876 PT-TLS February 2013

 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.

3.4. PT-TLS Message Flow

 This section discusses the general flow of messages between the NEA
 Client's Posture Transport Client and the NEA Server's Posture
 Transport Server in order to perform NEA assessments using the PT-TLS
 protocol.

3.4.1. Assessment Triggers

 Initially, the NEA Client or NEA Server will decide that an
 assessment is needed.  What stimulates the decision to perform an
 assessment is outside the scope of this specification, but some
 examples include:
 o  NEA Server becoming aware of suspicious behavior on an endpoint
 o  NEA Server receiving new policies requiring immediate action
 o  NEA Client noticing a change in local security posture
 o  NEA Client wishing to access a protected network or resource
 Because either the NEA Client or NEA Server can trigger the
 establishment of the TLS session and initiate the assessment, this
 document will use the terms "assessment initiator" and "assessment
 responder".  This nomenclature allows either NEA component to fill
 either of the PT-TLS roles.

Sangster, et al. Standards Track [Page 10] RFC 6876 PT-TLS February 2013

3.4.2. PT-TLS Message Exchange Phases

 The PT-TLS message exchange occurs in three distinct phases:
 o  TLS Setup (including TLS handshake protocol)
 o  PT-TLS Negotiation
 o  PT-TLS Data Transport
 The TLS Setup phase is responsible for the establishment of the TCP
 connection and the TLS protections for the PT-TLS messages.  The TLS
 Setup phase starts with the establishment of a TCP connection between
 the Posture Transport Client and Posture Transport Server.  The new
 connection triggers the TLS server to start the TLS handshake
 protocol to establish the cryptographic protections for the session.
 Once the TLS Setup phase has completed (after the TLS Finished
 messages), the TLS session MUST NOT be renegotiated.  TLS session
 renegotiation MAY be used before the TLS Setup phase ends and the
 PT-TLS Negotiation phase begins.  This phase also enables the
 establishment of the tls-unique shared secret.  The tls-unique shared
 secret can later be used by the PA protocol to protect against some
 forms of man-in-the-middle attacks.
 The PT-TLS Negotiation phase is only performed at the start of the
 first assessment on a TLS session.  During this phase, the NEA Client
 and NEA Server discover each other's PT-TLS capabilities and
 establish a context that will apply to all future PT-TLS messages
 sent over the TLS session.  The PT-TLS Negotiation phase MUST NOT be
 repeated after the session has entered the Data Transport phase.  NEA
 assessment messages (PB-TNC batches) MUST NOT be sent by the NEA
 Client or NEA Server prior to the completion of the PT-TLS
 Negotiation phase to ensure that the security protections for the
 session are properly established and applied to the NEA assessment
 messages.
 Finally, the Data Transport phase allows the NEA Client and NEA
 Server to exchange PT messages under the protection of the TLS
 session consistent with the capabilities established in earlier
 phases.  The exchanged messages can be a PT-TLS protected NEA
 assessment as described in this specification or other vendor-defined
 PT-TLS exchanged messages.

Sangster, et al. Standards Track [Page 11] RFC 6876 PT-TLS February 2013

3.4.2.1. TLS Setup Phase

 After a new TCP connection is established between the Posture
 Transport Client and Posture Transport Server, a standard TLS
 exchange is performed to negotiate a common security context for
 protecting subsequent communications.  As discussed in 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.

Sangster, et al. Standards Track [Page 12] RFC 6876 PT-TLS February 2013

 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.

3.4.2.2. PT-TLS Negotiation Phase

 Once a TLS session has been established between a Posture Transport
 Client and Posture Transport Server, the PT-TLS Initiator sends a
 Version Request message indicating its supported PT-TLS protocol
 version range.  Next, the PT-TLS Responder sends a Version Response
 message, which selects a protocol version from within the range
 offered.  The PT-TLS Responder SHOULD select the preferred version
 offered if supported; otherwise, the highest version that the
 responder is able to support from the received Version Request
 message will be used.  If the PT-TLS Responder is unable or unwilling
 to support any of the versions included in the Version Request
 message, the responder SHOULD send a Version Not Supported error
 message.
 If no client-side authentication occurred during the TLS Setup phase,
 the Posture Transport Server can authenticate the client using PT-TLS
 client authentication messages as described in 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

Sangster, et al. Standards Track [Page 13] RFC 6876 PT-TLS February 2013

 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.

3.4.2.3. PT-TLS Data Transport Phase

 Once a PT-TLS session is available to carry NEA assessments, PT-TLS
 allows either side of the connection to send the first PB-TNC batch.
 The PB-TNC standard prescribes whether the Posture Broker Client or
 Posture Broker Server starts the assessment.  The assessment
 initiator first envelopes the PB-TNC batch in a PT-TLS message, then
 assigns a message identifier to the message and finally transmits it
 over the session.  The assessment responder validates the PT-TLS
 message and delivers the encapsulated PB-TNC batch to its upstream
 component (Posture Broker Client or Server).
 Most PT-TLS messages contain PB-TNC batches that house PA-TNC
 requests for posture information or a response containing the
 requested posture information.  The Posture Transport Client and
 Posture Transport Server may also exchange messages between them,
 such as a PT-TLS Error message indicating that a problem occurred
 processing a message.  During an assessment, the Posture Transport
 Client and Server merely encapsulate and exchange the PB-TNC batches
 and are unaware of the state of the assessment.
 The PT-TLS protocol allows either party to send a PT-TLS message at
 any time, reflecting the full-duplex nature of the underlying TLS
 session.  For example, an assessment initiator may send several
 PT-TLS messages prior to receiving any responses from the assessment
 responder.  All implementations of PT-TLS MUST support full-duplex
 PT-TLS message exchange.  However, some higher-layer NEA protocols
 (e.g., PB-TNC) may not be able to fully make use of the full-duplex
 message exchange.

3.4.3. TLS Requirements

 In order to ensure that strong security is always available for
 deployers and to improve interoperability, this section discusses
 some requirements on the underlying TLS transport used by PT-TLS.
 Whenever TLS is used by this specification, the appropriate version
 (or versions) of TLS will vary over time, based on the widespread

Sangster, et al. Standards Track [Page 14] RFC 6876 PT-TLS February 2013

 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.

3.5. PT-TLS Message Format

 This section describes the format and semantics of the PT-TLS
 message.  Every message sent over a PT-TLS session MUST start with
 the PT-TLS header described in this section.
 The PT-TLS header format is as follows:
                        1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Reserved   |           Message Type Vendor ID              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Message Type                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Message Length                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Message Identifier                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Message Value (e.g., PB-TNC Batch) . . .       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Reserved
    Reserved for future use.  This field MUST be set to 0 on
    transmission and ignored upon reception.

Sangster, et al. Standards Track [Page 15] RFC 6876 PT-TLS February 2013

 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.

Sangster, et al. Standards Track [Page 16] RFC 6876 PT-TLS February 2013

    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.

Sangster, et al. Standards Track [Page 17] RFC 6876 PT-TLS February 2013

 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.

3.6. IETF Namespace PT-TLS Message Types

 This section defines the NEA standard PT-TLS Message Types used to
 carry PT-TLS messages and PB-TNC batches between the Posture
 Transport Client and Posture Transport Server.
 The following table summarizes the initial set of IETF-defined
 message type values, which are used with the PT-TLS Message Type
 Vendor ID field set to the IETF SMI PEN (0).  Note that the IANA
 administers a PEN value of 0 on behalf of the IETF.  These
 descriptions only apply to the IETF namespace.
        Value (Name)                          Definition
 ----------------------------  ---------------------------------------
 0 (Experimental)              Reserved for experimental use.  This
                               type will not offer interoperability
                               but allows for experimentation.  This
                               message type MUST only be sent when the
                               NEA Client and NEA Server are in the
                               Data Transport phase and only on a
                               restricted, experimental network.
                               Compliant implementations MUST send an
                               Invalid Message error code in a PT-TLS
                               Error message if an Experimental
                               message is received.
 1 (Version Request)           Version negotiation request including
                               the range of versions supported by the
                               sender.  This message type MUST only be
                               sent by the TLS session initiator as
                               the first PT-TLS message in the PT-TLS
                               Negotiation phase.  Recipients MUST
                               send an Invalid Message error code in a
                               PT-TLS Error message if a Version
                               Request is received at another time.

Sangster, et al. Standards Track [Page 18] RFC 6876 PT-TLS February 2013

 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.

Sangster, et al. Standards Track [Page 19] RFC 6876 PT-TLS February 2013

 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

3.7. PT-TLS Version Negotiation

 This section describes the message format and semantics for the
 PT-TLS protocol version negotiation.  This exchange is used by the
 PT-TLS Initiator to trigger a version negotiation at the start of an
 assessment.  The PT-TLS Initiator MUST send a Version Request message
 as its first PT-TLS message and MUST NOT send any other PT-TLS
 messages on this connection until it receives a Version Response
 message or an Error message.  The PT-TLS Responder MUST complete the
 version negotiation (or cause an error) prior to sending or accepting

Sangster, et al. Standards Track [Page 20] RFC 6876 PT-TLS February 2013

 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.

3.7.1. Version Request Message

 This message is sent by a PT-TLS Initiator as the first PT-TLS
 message in a PT-TLS session.  This message discloses the sender's
 supported versions of the PT-TLS protocol.  To ensure compatibility,
 this message MUST always be sent using version 1 of the PT-TLS
 protocol.  Recipients of this message MUST respond with a Version
 Response or with a PT-TLS Error message (Version Not Supported or
 Invalid Message).  The following diagram shows the format of the
 Version Request message:
                        1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Reserved   |    Min Vers   |    Max Vers   |   Pref Vers   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Reserved
    Reserved for future use.  This field MUST be set to 0 on
    transmission and ignored upon reception.
 Min Vers
    This field contains the minimum version of the PT-TLS protocol
    supported by the sender.  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.
 Max Vers
    This field contains the maximum version of the PT-TLS protocol
    supported by the sender.  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.

Sangster, et al. Standards Track [Page 21] RFC 6876 PT-TLS February 2013

 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.

3.7.2. Version Response Message

 This message is sent in response to receiving a Version Request
 message at the start of a new assessment session.  If a recipient
 receives a Version Request after a successful version negotiation has
 occurred on the session, the recipient MUST send an Invalid Message
 error code in a PT-TLS Error message and have TLS close the session.
 This message MUST be sent using the syntax, semantics, and
 requirements of the protocol version specified in this message.
                         1                   2                   3
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Reserved                      |    Version    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Reserved
    Reserved for future use.  This field MUST be set to 0 on
    transmission and ignored upon reception.
 Version
    This field contains the version selected by the sender of this
    message.  The version selected MUST be within the Min Vers to Max
    Vers inclusive range sent in the Version Request message.  If a
    PT-TLS Initiator receives a message with an invalid Version
    selected, the PT-TLS Initiator MUST respond with a Version Not
    Supported PT-TLS Error message.

3.8. Client Authentication Using SASL

 This section includes a description of the message format and
 semantics necessary to perform client authentication (authentication
 of the NEA Client) over PT-TLS.  Client authentication could be
 necessary if the NEA Server requires such an authentication and it
 was not performed during the TLS handshake.  The general model used

Sangster, et al. Standards Track [Page 22] RFC 6876 PT-TLS February 2013

 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.

3.8.1. SASL Client Authentication Requirements

 Implementations compliant with the PT-TLS specification MUST
 implement the PT-TLS client authentication messages described in this
 section.  These PT-TLS client authentication messages are capable of
 carrying a variety of SASL authentication mechanisms' exchanges.  In
 order to ensure interoperability, all PT-TLS implementations
 compliant with this specification MUST at least support the PLAIN
 SASL mechanism [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

Sangster, et al. Standards Track [Page 23] RFC 6876 PT-TLS February 2013

 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.

3.8.2. SASL in PT-TLS Overview

 Mechanism negotiation is initiated by the NEA Server sending the SASL
 Mechanisms TLV to the NEA Client to indicate the zero or more SASL
 mechanisms that the NEA Server's policy is willing to use with the
 NEA Client.  The NEA Client selects one SASL mechanism from the list
 and sends a SASL Mechanism Selection TLV completing the negotiation.
 Subsequent challenges and responses are carried within the SASL
 Authentication Data TLV carrying the authentication data for the
 selected mechanism.  The authentication outcome is communicated in a
 SASL Result TLV containing a status code.  If additional
 authentications are required, the NEA Server could trigger the next
 authentication by sending another SASL Mechanisms TLV after sending
 the SASL Result TLV for the current authentication mechanism.

3.8.3. SASL Authentication Flow

 The SASL client authentication starts when the NEA Server enters the
 PT-TLS Negotiation phase and its policy indicates that an
 authentication of the NEA Client is necessary, such as if it was not
 performed during the TLS handshake protocol.  The NEA Server is
 responsible for triggering the client authentication by sending the
 SASL Mechanisms TLV to the NEA Client listing the set of SASL
 mechanisms the server is willing to use based upon its policy.
 The NEA Client selects a SASL mechanism from the list proposed by the
 NEA Server or sends a PT-TLS Invalid Message error code indicating
 that it is unable or unwilling to perform any of the mechanisms that
 were offered.  If the NEA Server receives a SASL Mechanism Selection
 TLV that contains an unacceptable SASL mechanism, the NEA Server
 would respond with a SASL Mechanism Error in a PT-TLS Error TLV.
 In situations where the NEA Server does not require a client
 authentication, the NEA Server MUST send a SASL Mechanisms TLV with
 no mechanisms included (only the PT-TLS header) indicating that the
 connection should transition to the PT-TLS Data Transport phase.  The
 same mechanism is employed to indicate that a SASL authentication
 already performed in this session is adequate to permit transition to
 the PT-TLS Data Transport phase.  So the NEA Server MUST always send

Sangster, et al. Standards Track [Page 24] RFC 6876 PT-TLS February 2013

 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.

3.8.4. Aborting SASL Authentication

 The NEA Server may abort the authentication exchange by sending the
 SASL Result TLV with a status code of Abort.  The NEA Client may
 abort the authentication exchange by sending a PT-TLS Error message
 with an Error Code of SASL Mechanism Error.

3.8.5. Linkages to SASL Framework

3.8.5.1. SASL Service Name

 The service name for PT-TLS is "nea-pt-tls".

3.8.5.2. SASL Authorization Identity

 The PT-TLS protocol does not make use of a SASL authorization
 identity string as described in RFC 4422.

3.8.5.3. SASL Security Layer

 The NEA PT-TLS protocol always runs under the protection of TLS.
 SASL security layers are not used and thus MUST be negotiated off
 during SASL authentication.

3.8.5.4. Multiple Authentications

 Only one SASL mechanism authentication may be in progress at any one
 time.  Once a SASL mechanism completes (successfully or
 unsuccessfully), the NEA Server MAY trigger an additional
 authentication by sending a SASL Mechanisms TLV.

3.8.6. SASL Channel Bindings

 SASL channel bindings are used to bind the SASL authentication to the
 outer TLS tunnel to ensure that the authenticating endpoints are the
 same as the TLS endpoints.  For SASL mechanisms that support channel
 bindings, the tls-unique value defined in RFC 5929 is carried by the
 SASL mechanism.  For most mechanisms, this means including the

Sangster, et al. Standards Track [Page 25] RFC 6876 PT-TLS February 2013

 tls-unique value with the appropriate prefix defined in RFC 5929 in
 the application data portion of the SASL Mechanism channel-binding
 data.  If the validation of the channel binding fails, then the
 connection MUST be aborted.

3.8.7. SASL Mechanisms

 This TLV is sent by the NEA Server to indicate the list of SASL
 mechanisms that it is willing and able to use to authenticate the NEA
 Client.  Each mechanism name consists of a length followed by a name.
 The total length of the list is determined by the TLV Length field.
                        1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Rsvd| Mech Len|            Mechanism Name (1-20 bytes)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Rsvd| Mech Len|            Mechanism Name (1-20 bytes)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      . . . . . . . . . . .                    |
 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 with
    no padding.

3.8.8. SASL Mechanism Selection

 This TLV is sent by the NEA Client in order to select a SASL
 mechanism for use on this session.
                        1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Rsvd| Mech Len|            Mechanism Name (1-20 bytes)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Optional Initial Mechanism Response              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Sangster, et al. Standards Track [Page 26] RFC 6876 PT-TLS February 2013

 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.

3.8.9. SASL Authentication Data

 This TLV carries an opaque (to PT-TLS) blob of octets being exchanged
 between the NEA Client and the NEA Server.  This TLV facilitates
 their communications without interpreting any of the bytes.  The SASL
 Authentication Data TLV MUST NOT be sent until a SASL mechanism has
 been established for a session.  The SASL Authentication Data TLV
 associated with the current authentication mechanism MUST NOT be sent
 after a SASL Result is sent with a Result Code of Success.
 Additional SASL Authentication Data TLVs would be sent if the PT-TLS
 Initiator and Responder desire a subsequent SASL authentication to
 occur but only after another SASL mechanism selection exchange
 occurs.
                        1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                SASL Mechanism Data (Variable Length)          ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 SASL Mechanism Data
    Opaque, variable-length set of bytes exchanged between the PT-TLS
    Initiator's SASL mechanism and its peer PT-TLS Responder's SASL
    mechanism.  These bytes MUST NOT be interpreted by the PT-TLS
    layer.

Sangster, et al. Standards Track [Page 27] RFC 6876 PT-TLS February 2013

3.8.10. SASL Result

 This TLV is sent by the NEA Server at the conclusion of the SASL
 exchange to indicate the authentication result.  Upon reception of a
 SASL Result TLV indicating an Abort, the NEA Client MUST terminate
 the current authentication conversation.  The recipient may retry the
 authentication in the event of an authentication failure.  Similarly,
 the NEA Server may request that additional SASL authentication(s) be
 performed after the completion of a SASL mechanism by sending another
 SASL Mechanisms TLV including any mechanisms dictated by its policy.
                        1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Result Code         |    Optional Result Data       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      . . . . . . . . . . .                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Result Code
    This field contains the result of the SASL authentication
    exchange.
         Value (Name)                         Definition
    ---------------------  -------------------------------------------
    0 (Success)            SASL authentication was successful, and
                           identity was confirmed.
    1 (Failure)            SASL authentication failed.  This might be
                           caused by the client providing an invalid
                           user identity and/or credential pair.  Note
                           that this is not the same as a mechanism's
                           failure to process the authentication as
                           reported by the Mechanism Failure code.
    2 (Abort)              SASL authentication exchange was aborted by
                           the sender.
    3 (Mechanism Failure)  SASL "mechanism failure" during the
                           processing of the client's authentication
                           (e.g., not related to the user's input).
                           For example, this could occur if the
                           mechanism is unable to allocate memory
                           (e.g., malloc) that is needed to process a
                           received SASL mechanism message.

Sangster, et al. Standards Track [Page 28] RFC 6876 PT-TLS February 2013

 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.

3.9. Error Message

 This section describes the format and contents of the PT-TLS Error
 message sent by the NEA Client or NEA Server when it detects a
 PT-TLS-level protocol error.  Each error message contains an error
 code indicating the error that occurred, followed by a copy of the
 message that caused the error.
 When a PT-TLS error is received, the recipient MUST NOT respond with
 a PT-TLS error, because this could result in an infinite loop of
 error messages being sent.  Instead, the recipient MAY log the error,
 modify its behavior to avoid future errors, ignore the error,
 terminate the assessment, or take other action as appropriate (as
 long as it is consistent with the requirements of this
 specification).
 The Message Value portion of a PT-TLS Error message contains the
 following information:
                        1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Reserved   |               Error Code Vendor ID            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Error Code                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Copy of Original Message (Variable Length)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           . . . . . . .                       |
 Reserved
    Reserved for future use.  This field MUST be set to 0 on
    transmission and ignored upon reception.

Sangster, et al. Standards Track [Page 29] RFC 6876 PT-TLS February 2013

 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

Sangster, et al. Standards Track [Page 30] RFC 6876 PT-TLS February 2013

                               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.

Sangster, et al. Standards Track [Page 31] RFC 6876 PT-TLS February 2013

    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.

4. Security Considerations

 This section discusses the major threats potentially faced by each
 binding of the PT protocol and countermeasures provided by the PT-TLS
 protocol.

4.1. Trust Relationships

 In order to understand where security countermeasures are necessary,
 this section starts with a discussion of where the NEA architecture
 envisions some trust relationships between the processing elements of
 the PT-TLS protocol.  Implementations or deployments where these
 trust relationships are not present would need to provide additional
 countermeasures to ensure the proper operation and security of PT-TLS
 (which relies upon these relationships to be trustworthy).  The
 following subsections discuss the trust properties associated with
 each portion of the NEA reference model directly involved with the
 processing of the PT-TLS protocol.

Sangster, et al. Standards Track [Page 32] RFC 6876 PT-TLS February 2013

4.1.1. Posture Transport Client

 The Posture Transport Client is trusted by the Posture Broker
 Client to:
 o  Not observe, fabricate, or alter the contents of the PB-TNC
    batches received from the network
 o  Not observe, fabricate, or alter the PB-TNC batches passed down
    from the Posture Broker Client for transmission on the network
 o  Transmit on the network any PB-TNC batches passed down from the
    Posture Broker Client
 o  Deliver properly security protected messages received from the
    network that are destined for the Posture Broker Client
 o  Provide configured security protections (e.g., authentication,
    integrity, and confidentiality) for the Posture Broker Client's
    PB-TNC batches sent on the network
 o  Expose the authenticated identity of the Posture Transport Server
    only to the PB-TNC layer within the NEA Client
 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  Provide a secure, reliable, "in-order delivery", full-duplex
    transport for the Posture Broker Client's messages
 The Posture Transport Client is trusted by the Posture Transport
 Server to:
 o  Not send malicious traffic intending to harm (e.g., denial of
    service) the Posture Transport Server
 o  Not send malformed messages (e.g., messages lacking a PT-TLS
    header)
 o  Not send invalid or incorrect responses to messages (e.g., errors
    when no error is warranted)
 o  Not ignore or drop messages when such an action would cause issues
    for the protocol processing (e.g., dropping PT-TLS SASL
    Authentication Data messages)

Sangster, et al. Standards Track [Page 33] RFC 6876 PT-TLS February 2013

 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

4.1.2. Posture Transport Server

 The Posture Transport Server is trusted by the Posture Broker
 Server to:
 o  Not observe, fabricate, or alter the contents of the PB-TNC
    batches received from the network
 o  Not observe, fabricate, or alter the PB-TNC batches passed down
    from the Posture Broker Server for transmission on the network
 o  Transmit on the network any PB-TNC batches passed down from the
    Posture Broker Server
 o  Deliver properly security protected messages received from the
    network that are destined for the Posture Broker Server
 o  Provide configured security protections (e.g., authentication,
    integrity, and confidentiality) for the Posture Broker Server's
    messages sent on the network
 o  Expose the authenticated identity of the Posture Transport Client
    only to the PB-TNC layer within the NEA Server
 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  Provide a secure, reliable, "in-order delivery", full-duplex
    transport for the Posture Broker Server's messages
 The Posture Transport Server is trusted by the Posture Transport
 Client to:
 o  Not send malicious traffic intending to harm (e.g., denial of
    service) the Posture Transport Client
 o  Not send malformed messages (e.g., messages lacking a PT-TLS
    header)
 o  Not send invalid or incorrect responses to messages (e.g., errors
    when no error is warranted)

Sangster, et al. Standards Track [Page 34] RFC 6876 PT-TLS February 2013

 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

4.2. Security Threats and Countermeasures

 Beyond the trust relationships assumed in 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.

4.2.1. Message Theft

 When PT-TLS messages are sent over unprotected network links or
 spanning local software stacks that are not trusted, the contents of
 the messages may be subject to information theft by an intermediary
 party.  This theft could result in information being recorded for
 future use or analysis by the adversary.  Messages observed by
 eavesdroppers could contain information that exposes potential
 weaknesses in the security of the endpoint, or system fingerprinting
 information; this information would make it easier for the attacker
 to employ attacks more likely to be successful against the endpoint.
 The eavesdropper might also learn information about the endpoint or
 network policies that either singularly or collectively is considered
 sensitive information.  For example, if PT-TLS does not provide
 confidentiality protection, an adversary could observe the PA-TNC
 attributes included in the PT-TLS message and determine that the
 endpoint is lacking patches or that particular sub-networks have more
 lenient policies.
 In order to protect against NEA assessment message theft, the PT-TLS
 protocol provides strong cryptographic authentication, integrity, and
 confidentiality protection.  Deployers are strongly encouraged to
 employ "best practice of the day" TLS ciphers to ensure that the
 information remains safe despite advances in technology and
 discovered cipher weaknesses.  The use of bidirectional
 authentication of the assessment transport session ensures that only
 properly authenticated and authorized parties may be involved in an

Sangster, et al. Standards Track [Page 35] RFC 6876 PT-TLS February 2013

 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.

4.2.2. Message Fabrication

 Attackers on the network or present within the NEA system could
 introduce fabricated PT-TLS messages intending to trick or create a
 denial of service against aspects of an assessment.  For example, an
 adversary could attempt to insert into the message exchange fake
 PT-TLS Error Codes in order to disrupt communications.
 The PT-TLS protocol provides strong security protections for the
 complete message exchange over the network.  These security
 protections prevent an intermediary from being able to insert fake
 messages into the assessment.  In particular, TLS's use of hashing
 algorithms provides strong integrity protections that allow for
 detection of any changes in the content of the message stream.
 Additionally, adversaries are unable to observe the PT-TLS protocol
 exchanges because they are encrypted by the TLS ciphers and so would
 have difficulty determining where to insert the falsified message,
 since the attacker is unable to determine where the message
 boundaries exist.  Even if a successful message insertion did occur,
 the recipient would be able to detect it due to failure of the TLS
 cipher suite's integrity check.

4.2.3. Message Modification

 This attack could allow an active attacker capable of intercepting a
 message to modify a PT-TLS message or transported PA-TNC attribute to
 a desired value to make it easier to compromise an endpoint.  Without
 the ability for message recipients to detect whether a received
 message contains the same content as what was originally sent, active
 attackers can stealthily modify the attribute exchange.
 The PT-TLS protocol leverages the TLS protocol to provide strong
 authentication and integrity protections as a countermeasure to this
 threat.  The bidirectional authentication prevents the attacker from
 acting as an active man-in-the-middle to the protocol that could be
 used to modify the message exchange.  The strong integrity protection
 (e.g., hashing) offered by TLS allows PT-TLS message recipients to
 detect message alterations by other types of network-based
 adversaries.

Sangster, et al. Standards Track [Page 36] RFC 6876 PT-TLS February 2013

4.2.4. Denial of Service

 A variety of types of denial-of-service attacks are possible against
 the PT-TLS protocol if the message exchanges are left unprotected
 while traveling over the network.  The Posture Transport Client and
 Posture Transport Server are trusted not to participate in the denial
 of service of the assessment session, leaving the threats to come
 from the network.
 The PT-TLS protocol provides bidirectional authentication
 capabilities in order to prevent a man-in-the-middle on the network
 from becoming an undetected active proxy of PT-TLS messages.  Because
 the PT-TLS protocol runs after the TLS handshake and thus cipher
 establishment/use, all of the PT-TLS messages are protected from
 undetected modification that could create a denial-of-service
 situation.  However, it is possible for an adversary to alter the
 message flows, causing each message to be rejected by the recipient
 because it fails the integrity checking.
 The PT-TLS protocol operates as an application protocol on top of TLS
 and thus TCP/IP protocols, so is subject to denial-of-service attacks
 against the TLS, TCP, and IP protocols.

4.2.5. NEA Asokan Attacks

 As described in 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.

Sangster, et al. Standards Track [Page 37] RFC 6876 PT-TLS February 2013

4.2.6. Trust Anchors

 The TLS protocol bases its trust decision about the signer of the
 certificates received during the TLS authentication on using a set of
 trust anchor certificates.  It is essential that these trust anchor
 certificates are integrity protected from unauthorized modification.
 Many common software components (e.g., browsers, operating systems,
 security protocols) include a set of trust anchor certificates that
 are relevant to their operation.  The PT-TLS SHOULD use a PT-TLS-
 specific set of trust anchor certificates in order to limit what
 Certificate Authorities are authorized to issue certificates for use
 with NEA.

5. Privacy Considerations

 The role of PT-TLS is to act as a secure transport for PB-TNC and
 other higher-layer protocols.  As such, PT-TLS does not directly
 utilize personally identifiable information (PII) except when client
 authentication is enabled.  When client authentication is being used,
 the NEA Client will be asked to use SASL, which may disclose a local
 identifier (e.g., username) associated with the endpoint and an
 authenticator (e.g., password) to authenticate that identity.
 Because the identity and authenticator are potentially privacy-
 sensitive information, the NEA Client MUST offer a mechanism to
 restrict which NEA Servers will be sent this information.  Similarly,
 the NEA Client SHOULD provide an indication to the person being
 identified that a request for their identity has been made in case
 they choose to opt out of the authentication to remain anonymous
 unless no user interface is available.  PT-TLS provides cryptographic
 peer authentication, message integrity, and data confidentiality
 protections to higher-layer NEA protocols that may exchange data
 potentially including PII.  These security services can be used to
 protect any PII involved in an assessment from passive and active
 attackers on the network.  Endpoints sending potentially privacy-
 sensitive information SHOULD ensure that the PT-TLS security
 protections (TLS cipher suites) negotiated for an assessment of the
 endpoint are adequate to avoid interception and off-line attacks of
 any long-term privacy-sensitive information unless other network
 protections are already present.

6. IANA Considerations

 Per this specification, two new IANA registries have been created and
 a TCP port number has been assigned.  IANA has permanently reserved
 the early allocated TCP port number 271 for use with the PT-TLS
 protocol.

Sangster, et al. Standards Track [Page 38] RFC 6876 PT-TLS February 2013

 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.

6.1. Designated Expert Guidelines

 For each of the IANA registries defined by this specification, new
 values are added to the registry by following the IANA Specification
 Required policy [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.

Sangster, et al. Standards Track [Page 39] RFC 6876 PT-TLS February 2013

 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.

6.2. Registry for PT-TLS Message Types

 The name for this registry is "PT-TLS Message Types".  Each entry in
 this registry should include a human-readable name, an SMI Private
 Enterprise Number, a decimal integer value between 0 and 4294967294,
 and a reference to the specification where the contents of this
 message type are defined.  This specification must define the meaning
 of the PT-TLS Message Type and the format and semantics of the PT-TLS
 Message Value field that include the designated Private Enterprise
 Number in the PT-TLS Message Type Vendor ID field and the designated
 numeric value in the PT-TLS Message Type field.
 The following entries for this registry are defined in this document.
 Additional entries to this registry are added by following the IANA
 Specification Required policy, consistent with the guidelines in
 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.

Sangster, et al. Standards Track [Page 40] RFC 6876 PT-TLS February 2013

6.3. Registry for PT-TLS Error Codes

 The name for this registry is "PT-TLS Error Codes".  Each entry in
 this registry should include a human-readable name, an SMI Private
 Enterprise Number, a decimal integer value between 0 and 4294967295,
 and a reference to the specification where this error code is
 defined.  This specification must define the meaning of this error
 code, a PT-TLS Message Type of PT-TLS Error, the designated Private
 Enterprise Number in the PT-TLS Error Code Vendor ID field, and the
 designated numeric value in the PT-TLS Error Code field.
 The following entries for this registry are defined in this document.
 Additional entries to this registry are added following the IANA
 Specification Required policy, consistent with the guidelines in
 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.

7. Acknowledgments

 Thanks to the Trusted Computing Group for contributing the initial
 text upon which this document was based [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.

Sangster, et al. Standards Track [Page 41] RFC 6876 PT-TLS February 2013

8. References

8.1. Normative References

 [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.

Sangster, et al. Standards Track [Page 42] RFC 6876 PT-TLS February 2013

 [RFC6520]   Seggelmann, R., Tuexen, M., and M. Williams, "Transport
             Layer Security (TLS) and Datagram Transport Layer
             Security (DTLS) Heartbeat Extension", RFC 6520,
             February 2012.

8.2. Informative References

 [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.

Sangster, et al. Standards Track [Page 43] RFC 6876 PT-TLS February 2013

Authors' Addresses

 Paul Sangster
 Symantec Corporation
 6825 Citrine Dr.
 Carlsbad, CA  92009
 EMail: paul_sangster@symantec.com
 Nancy Cam-Winget
 Cisco Systems
 80 West Tasman Drive
 San Jose, CA  95134
 US
 EMail: ncamwing@cisco.com
 Joseph Salowey
 Cisco Systems
 2901 Third Avenue
 Seattle, WA  98121
 US
 EMail: jsalowey@cisco.com

Sangster, et al. Standards Track [Page 44]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6876.txt · Last modified: 2013/02/27 19:11 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki