<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
  which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced. 
An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2434 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2434.xml">
<!ENTITY RFC3748 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml">
<!ENTITY RFC4493 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4493.xml">
<!ENTITY RFC5929 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5929.xml">
<!ENTITY RFC5793 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5793.xml">
<!ENTITY RFC4422 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4422.xml">
<!ENTITY salowey-nea-asokan SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.salowey-nea-asokan.xml">
<!ENTITY I-D.ietf-nea-pa-tnc SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nea-pa-tnc.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors --><!-- For a complete list and description of processing instructions (PIs), 
  please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
  (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
  (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-cam-winget-eap-tlv-03" ipr="pre5378Trust200902">
  

  
  <front>
    <title abbrev="TLS Based NEA Transports">Transport Layer Security (TLS) Based Transports for Network Endpoint Assessment (NEA) Protocol Exchanges</title>

    <author fullname="Nancy Cam-Winget" initials="N" surname="Cam-Winget">
      <organization abbrev="">Cisco Systems</organization>

      <address>
        <postal>
          <street>80 West Tasman Drive</street>

          <city>San Jose</city>

          <country>US</country>

          <code>95134</code>

          <region>CA</region>
        </postal>

        <email>ncamwing@cisco.com</email>
      </address>
    </author>

    <author fullname="Joseph Salowey" initials="J" surname="Salowey">
      <organization abbrev="">Cisco Systems</organization>

      <address>
        <postal>
          <street>2901 Third Avenue</street>

          <city>Seattle</city>

          <country>US</country>

          <code>98121</code>

          <region>WA</region>
        </postal>

        <email>jsalowey@cisco.com</email>
      </address>
    </author>

    <author fullname="Hao Zhou" initials="H" surname="Zhou">
      <organization abbrev="">Cisco Systems</organization>

      <address>
        <postal>
          <street>4125 Highlander Parkway</street>

          <city>Richfield</city>

          <country>US</country>

          <code>44286</code>

          <region>OH</region>
        </postal>

        <email>hzhou@cisco.com</email>
      </address>
    </author>

    <date month="March" year="2011" />

    <abstract>

      <t> This document describes how Network Endpoint Assessment (NEA) data can be carried
        under the protection of a Transport Layer Security (TLS) secured tunnel.  This document defines NEA transports for TLS-based Extensible Authentication Protocol (EAP) tunnel methods and for TLS used over TCP.  </t>
    </abstract>
  </front>

<middle>
    <section anchor="introduction" title="Introduction">
      
      <t>NEA has standardized a transport agnostic Posture Broker (PB) protocol defined
        in <xref target="RFC5793"></xref> to effect a network endpoint assessment
        between a Posture Broker Client and a Posture Broker Server.  These PB messages
	can be transported inside the already defined Type-Length-Value containers in
	existing TLS-based tunne EAP methods such as PEAP, EAP-FAST and TTLS.  Similarly, this document also defines a TCP based transport, PT-TCP, that uses TLVs encapsulated within TLS.   </t>

     </section>

      <section title="Specification Requirements">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in <xref
        target="RFC2119"></xref> .</t>
      </section>

            
	<section anchor="protocol-layering" title="Protocol Layering Model">
	  <t> When using EAP as the transport, the PB messages can be encapsulated in the TLVs
	  defined by the tunnel EAP methods.  For TLS a new TLV container is defined to facilitate
	  the PB transport over TCP.
	  The following diagram demonstrates the relationship between protocols when an EAP tunnel method is used: </t>
 <figure title="EAP based Protocol Layering Model">
          <artwork><![CDATA[
	
 +---------------------------------------------------------------+ 
 |          TLV Encapsulation of PB-PA message                   | 
 |---------------------------------------------------------------| 
 |                         TLS                                   | 
 |---------------------------------------------------------------| 
 |                EAP tunnel based method                      | 
 |---------------------------------------------------------------| 
 |                         EAP                                   | 
 |---------------------------------------------------------------| 
 |        Carrier Protocol (EAPOL, RADIUS, Diameter, etc.)       | 
 +---------------------------------------------------------------+ 
	
	]]></artwork>
        </figure>

	<t> The following diagram demonstrates the protocol relationship of PB when PT-TCP is used: </t>
 <figure title="PT-TCP based Protocol Layering Model">
          <artwork><![CDATA[
	
 +---------------------------------------------------------------+ 
 |           TLV Encapsulation of PB-PA message                  | 
 |---------------------------------------------------------------| 
 |                         TLS                                   | 
 +---------------------------------------------------------------+ 
 |                         TCP                                   | 
 +---------------------------------------------------------------+ 
	
	]]></artwork>
        </figure> 
	</section>
<section anchor="flows" title="Protocol Flows">
<t> There are two distinct phases in TLS based transport operation: </t>
  <t> <list style="numbers">
    <t> TLS Setup Phase: are the messages used to establish TLS
    channel protection for the posture messages.  The TLS Setup Phase begins with either
    the Posture Transport Client or Posture Transport Server initiating the TLS Handshake
    protocol to establish the protected TLS channel. </t>
    <t> Data Transport Phase: are the messages that are
    protected by the TLS Record encapsulation. This phase is usually broken up into an optional entity authentication phase followed by the exchange of TLVs carrying NEA data. </t>
  </list></t>
<section anchor="tlsflow" title="PT-TCP Protocol Flow">
  

    <t> This section describes the general flow of messages between the NEA 
Posture Transport Client and the NEA Posture Transport Server.</t>

<section anchor="inittls" title="Initiating a PT-TCP session">
<t>With the use of TLS as the transport, it is possible for either the Posture Transport
Client or the Posture Transport Server to initiate a PT-TCP session.</t>
</section>

<section anchor="tcpport" title="TCP Port Usage">
<t>IANA is requested to allocate a TCP Port number for the use of PT-TCP so that
both the Posture Transport Client and Posture Transport Server can communicate
on a known allocated port.</t>
</section>

<section anchor="tlssetup" title="TLS Setup Phase">
<t> Typically, it is the NEA Client (e.g. the Posture Transport Client) that
initiates the TLS Setup Phase.  However, either party, e.g. the Posture Transport Client or the
Posture Transport Server may establish a TCP connection and initiate the TLS Handshake
protocol.  Furthermore, the TLS Handshake protocol is also used to
establish the cryptographic protections used to secure the data carried
within TLS Records.</t>

<t> In typical deployments, it is expected for the initiator of a NEA exchange
to initiate the TLS Setup.  However, this specification allows for multiple
NEA data transactions and as such, each transaction may originate from either
the NEA client or the NEA server.  Furthermore, through the use of the TLS 
session capabilities, PT-TCP 
also allows for the re-use of the TLS based (PT-TCP) session to allow either
the NEA Client or the NEA Server to trigger subsequent NEA exchanges. </t>
</section>

<section anchor="tlsneaxport" title="NEA Data Transport Phase in PT-TCP">
<t> Once the PT-TCP session has been established, either the NEA Client or the
NEA Server can trigger a NEA data transaction (typically a posture assessment).
The initiator for the NEA data transaction encapsulates the PB messages in
a TLV as described in <xref target="tlsfmt"></xref>. </t>

<t> As PT-TCP is full-duplex (by the TLS design), it supports the full capabilities
of the PB-TNC state machine.</t>
</section>

<section anchor="sasl" title="Entity Authentication using SASL in PT-TCP" >
<t>Implementations may support entity authentication through the use of <xref target="RFC4422">SASL</xref>.  This section details the SASL profile for PT-TCP. </t>

<t>Typically, the PT-TCP initiator will also initiate the SASL exchange.  The responder presents a list of SASL mechanism it supports through the use of the SASL-AUTH-MECH TLV.  The initiator may request a list of SASL authentication mechanisms by sending an empty list of mechanisms in the SASL-AUTH-MECH TLV.</t>

<t>The initiator starts the authentication by sending a SASL-AUTH TLV with the mech field containing the name of the mechanism it selects.  If the selected mechanism has an initial response then the client includes that response in the auth-data field.  If necessary the responder sends a SASL-AUTH TLV with the auth-data field containing a SASL challenge for the selected mechanism.  The SASL-AUTH exchange continues in this manner until the authentication completes upon completion the responder sends a SASL-RESULT TLV.  If the authentication is successful the SASL-RESULT TLV contains an result code of success.  If the authentication fails the SASL-RESULT TLV contains a result code indicating the reason for the failure.   The initiator may abort the exchange by sending a SASL-RESULT TLV with an ABORT result code.</t> 

<t>Implementations MUST provide the EXTERNAL SASL mechanism if the initiator is authenticated during the TLS establishment.  Implementations MUST also support the PLAIN SASL mechanism. 
</t>
<section title="Service Name">
<t>The service name for PT-TCP is "nea-pt-tcp".</t>
</section>
<section title="Mechanism Negotiation">
<t>Mechanism Negotiation is performed using the SASL-AUTH-MECH TLV.  The SASL-AUTH-MECH TLV contains the list of mechanisms supported by the responder.  The initiator may send a SASL-AUTH-MECH TLV with an emptily list to request a list format from the responder. </t>
</section>
<section title="Message Definition">
<t>The initiator starts authentication by sending a SASL-AUTH TLV indicating the sleeted mechanism.  The initial message may contain an initial response if required by the selected mechanism.  Subsequent challenges and response are carried within SASL-AUTH TLVs between the initiator and responder carrying the authentication data for the mechanism.  The authentication outcome is communicated in a SASL-RESULT TLV containing a status code. </t>
</section>
<section title="Authorization Identity">
<t>The nea-pt-tcp protocol does not make use of an authorization identity.</t>
</section>
<section title="Aborting Authentication">
<t>The initiator may abort the authentication exchange by sending the SASL-AUTH-RESULT TLV with a status code of ABORT.</t>
</section>
<section title="Security Layers">
<t>The NEA PT-TCP protocol always runs under the protection of TLS. SASL security layers are not used. </t>
</section>
<section title="Multiple Authentications">
<t>Only one authentication may be in progress at any one time.  Once an authentication completes, successfully on unsuccessfully, a new authentication may be initiated.  
</t>
</section>
</section>
</section>

  <section anchor="eapflow" title="Tunnel EAP Message Flow">
	    <t>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 when using a tunnel EAP method. </t>

	   <t> When NEA data exchange is conducted in a tunnel EAP method, it typically consists of four phases:</t>
	    <t> <list style="numbers">
	      <t>Establishment of EAP tunnel method: a secure and protected TLS channel is established between the Transport Client and Transport Server, after the Transport Server's identity has been authenticated and a shared secret encryption key is established between them.</t>

	      <t>Entity authentication: during this phase, the NEA Client's Posture Transport Client's identity might be optionally authenticated, so appropriate posture assessment policy could be applied according to the authenticated entity. Typically, it is done via an inner EAP method or authentication exchanges within the protected tunnel. In addition, the identity could also be authenticated as part of the tunnel establishment instead (e.g., the client sends a client certificate as part of the tunnel establishment). </t>
	      <t>Posture assessment: the posture data are exchanged between the NEA Client's Posture Transport client and NEA Server's Posture Transport Server. The posture data is encapsulated in a TLV or TLV like type object, as described in Section 5.2. </t>
	      <t>Conclusion phase: the result of the authentication and/or posture assessment is exchanged between the client and server, so they will have synchronized state. Optional cryptographic binding might be done to ensure both peers are involved in both the tunnel establishment and the inner method exchanges. Both sides are ready to tear down the tunnel and finish the EAP method. </t>
	    </list> </t>

	    <t>At the end of the tunnel EAP method, an EAP-Success or EAP-Failure will be sent by the EAP server to indicate the end of the EAP authentication, and the NAS will apply appropriate authorization policy based on the authentication and posture assessment result. </t>
	  </section>
	</section>

        <section anchor="neaformat" title="Packet Formats">
	  <t>As there is no explicit authentication expected in the PB-PA message
	  exchanges, no new inner EAP method is required; rather, the TLV formats defined
	  in existing EAP tunnel methods can be used to encapsulate and
	  transport PB-PA messages.  Similarly, when using TLS a TLV format can be defined
	  to carry NEA data.  This section describes how NEA data can be carried in
	  either a tunnel EAP method or TLS. </t>

	  <section anchor="tlsfmt" title="PT-TCP transport Format">
          <t>This section defines a Type-Length-Value (TLV) encapsulation for carrying
	  NEA data in a TLS channel.  The TLS channel MUST be protected to carry NEA
	  data using the encapsulation defined below. The fields are transmitted
          from left to right.</t>
<figure>
            <artwork><![CDATA[
 0                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R |            TLV Type       |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Length            |      Data                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Data                                 |                                          
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
          </figure>

  <t><list hangIndent="0" style="hanging">
              <t><list hangIndent="3" style="hanging">
                 
                  <t hangText="R"><vspace blankLines="1" />Reserved, set to
                  zero (0)<vspace blankLines="1" /></t> </list> </t>

                  <t hangText="TLV Type"><vspace blankLines="1" /> TLV Type Code. Allocated Types include:<vspace blankLines="1" /> <list>
		  <t hangText="0">Reserved</t>
		  <t hangText="1">NEA TLV</t>
		  <t hangText="2">SASL-MECH TLV</t>
		  <t hangText="3">SASL-AUTH TLV</t>
		  <t hangText="4">SASL-RESULT TLV</t>
		  </list> <vspace blankLines="1" /></t>

                  <t hangText="Length"><vspace blankLines="1" />The length of
                  the Data field in octets.<vspace blankLines="1" /></t>

                  <t hangText="Data"><vspace blankLines="1" /> Data according to the TLV type.</t>
                </list>
</t>
	   

<section title="NEA TLV">


<figure>
            <artwork><![CDATA[
 0                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R |            TLV Type       |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Length            |       PB-TNC Header           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        PB-TNC Header          |     PB-PA Message...          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          PB-PA Message...                     |                                      
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
          </figure>

          <t><list hangIndent="0" style="hanging">
              <t><list hangIndent="3" style="hanging">
                 
                  <t hangText="R"><vspace blankLines="1" />Reserved, set to
                  zero (0)<vspace blankLines="1" /></t> </list> </t>

                  <t hangText="TLV Type"><vspace blankLines="1" /> 1 for NEA TLV
                  <vspace blankLines="1" /></t>

                  <t hangText="Length"><vspace blankLines="1" />The length of
                  the Value field in octets.<vspace blankLines="1" /></t>

                  <t hangText="PB-TNC Header"><vspace blankLines="1" /> The PB-TNC
                    encapsulation header as described in <xref target="RFC5793"></xref>.</t>
                
                <t hangText="PB-PA Message"><vspace blankLines="1" /> The message between the
                  Posture Broker Client and Posture Broker Server as described in 
                  <xref target="RFC5793"></xref>.</t>
	      </list> </t>

        </section>
<section title="SASL-MECH TLV">
<figure>
            <artwork><![CDATA[
 0                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R |            TLV Type       |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Length            |      Mech-Name-Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Mechanism Name                                    |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Mech-Name-Length           |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
|             Mechanism Name                                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...




]]></artwork>
          </figure>
<t>The SASL-MECH TLV contains a list of supported SASL mechanisms.  Each mechanism name consists of a name length followed by the name.  The total length of the list is determined by the TLV length field.</t>  
          <t><list hangIndent="0" style="hanging">
              <t><list hangIndent="3" style="hanging">
                 
                  <t hangText="R"><vspace blankLines="1" />Reserved, set to
                  zero (0)<vspace blankLines="1" /></t> </list> </t>

                  <t hangText="TLV Type"><vspace blankLines="1" /> 2 for SASL-MECH TLV
                  <vspace blankLines="1" /></t>

                  <t hangText="Length"><vspace blankLines="1" />The length of
                  the Value field in octets.  The value field contains the list of mechanism names.<vspace blankLines="1" /></t>

                  <t hangText="Mech-Name-Length"><vspace blankLines="1" /> Length of the mechanism name in bytes.</t>
                
                <t hangText="Mech-Name"><vspace blankLines="1" /> SASL mechanism Name adhering to the rules defined in <xref target="RFC4422"></xref>.</t>
	      </list> </t>
</section>
<section title="SASL-AUTH TLV">
<figure>
            <artwork><![CDATA[

 0                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R |            TLV Type       |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Length            |      Mech-Name-Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Mechanism Name                                    |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                                                               |
|               Mechanism Data                                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
          </figure>
<t>The SASL-AUTH TLV contains data pertaining a SASL mechanism.  The mechanism name is included in each SASL-AUTH TLV.  The TLV is used by the initiator to select from a list of supported mechanisms provided by the responder.  The initial response from the initiator may contain Mechanism Data containing the initial response.  If the mechanism selected does not use an initial response then the mechanism data field is not included.  The SASL-AUTH TLV is also used to communicate SASL mechanism data from the responder to the initiator. </t>  
          <t><list hangIndent="0" style="hanging">
              <t><list hangIndent="3" style="hanging">
                 
                  <t hangText="R"><vspace blankLines="1" />Reserved, set to
                  zero (0)<vspace blankLines="1" /></t> </list> </t>

                  <t hangText="TLV Type"><vspace blankLines="1" /> 3 for SASL-AUTH TLV
                  <vspace blankLines="1" /></t>

                  <t hangText="Length"><vspace blankLines="1" />The length of
                  the Value field in octets.  The value field contains a mechanism name and optional mechanism data..<vspace blankLines="1" /></t>

                  <t hangText="Mech-Name-Length"><vspace blankLines="1" /> Length of the mechanism name in bytes.</t>
                
                <t hangText="Mech-Name"><vspace blankLines="1" /> SASL mechanism Name adhering to the rules defined in <xref target="RFC4422"></xref>.  This is the mechanism selected for use by the initiator.</t>
<t hangText="Mech-Name"><vspace blankLines="1" /> SASL mechanism data for named mechanism.  This field may be omitted in the initial response from the initiator if the selected mechanism does not use an initial response.</t>
	      </list> </t>
</section>
<section title="SASL-RESULT TLV">
<figure>
            <artwork><![CDATA[


 0                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R |            TLV Type       |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Length            |       Result-Code             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


]]></artwork>
          </figure>
<t>The SASL-RESULT TLV contains the result of the SASL Exchange. A result code of 0 indicates success. Other result codes indicate some sort of failure.  A result code of 1 indicates the exchange was aborted by the sender. A result code of 2 indicates a failure within the mechanism.  Only the responder side of the conversation may send a successful result code.  Either side may send a failure result code which terminates the current authentication conversation.</t>  
          <t><list hangIndent="0" style="hanging">
              <t><list hangIndent="3" style="hanging">
                 
                  <t hangText="R"><vspace blankLines="1" />Reserved, set to
                  zero (0)<vspace blankLines="1" /></t> </list> </t>

                  <t hangText="TLV Type"><vspace blankLines="1" /> 4 for SASL-Result TLV
                  <vspace blankLines="1" /></t>

                  <t hangText="Length"><vspace blankLines="1" />The length of
                  the Value field in octets.  This field is set to 2.<vspace blankLines="1" /></t>

                 <t hangText="Result Code"><vspace blankLines="1" /> The value of the result code.
                 <vspace blankLines="1" /><list>
                      
                    <t hangText="0">Success</t>
		    <t hangText="1">Abort</t>
		    <t hangText="2">Mechanism Failure</t>

                    </list><vspace blankLines="1" /></t>
               
	      </list> </t>
</section>
</section>

<section anchor="eapxport" title="Using tunnel EAP to transport NEA data">
	  <t>This section describes the TLV encapsulation used in three predominant tunnel
	  EAP methods deployed today: PEAP, EAP-FAST and TTLS.  When using EAP tunnel
	  methods, the tunnel MUST be protected.</t>

	  <section anchor="eap-fast" title="Carrying NEA data in PEAP or EAP-FAST">
	    <t>As TLV format for PEAP and EAP-FAST are the same, the diagram below shows
	    how PB-PA messages can be encapsulated in the TLVs.  Note however that the type
	    assignments when using PEAP versus EAP-FAST may be different. The fields are transmitted
          from left to right.</t>

          <figure>
            <artwork><![CDATA[
 0                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|            TLV Type       |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          PB-TNC Header                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          PB-PA Message...                     |                                      
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
          </figure>

          <t><list hangIndent="0" style="hanging">
              <t><list hangIndent="3" style="hanging">
                  <t hangText="M"><vspace blankLines="1" /><list>
                      <t hangText="0">Optional TLV</t>

                      <t hangText="1">Mandatory TLV<vspace
                      blankLines="1" /></t>
                    </list></t>

                  <t hangText="R"><vspace blankLines="1" />Reserved, set to
                  zero (0)<vspace blankLines="1" /></t>

                  <t hangText="TLV Type"><vspace blankLines="1" /> The EAP-FAST NEA TLV type:
                  <vspace blankLines="1" /><list>
                      
                    <t hangText="TBD"></t>

                    </list><vspace blankLines="1" /></t>

                  <t hangText="Length"><vspace blankLines="1" />The length of
                  the Value field in octets.<vspace blankLines="1" /></t>

                  <t hangText="PB-TNC Header"><vspace blankLines="1" /> The PB-TNC
                    encapsulation header as described in <xref target="RFC5793"></xref>.</t>
                
                <t hangText="PB-PA Message"><vspace blankLines="1" /> The message between the
                  Posture Broker Client and Posture Broker Server as described in 
                  <xref target="RFC5793"></xref>.</t>
		</list></t></list></t> 
	  </section>

<section anchor="ttls" title="Carrying NEA data in TTLS">
	    <t>The TTLS AVP Format to carry PB-PA messages is defined and described below. The fields are transmitted
          from left to right.</t>

          <figure>
            <artwork><![CDATA[
 0                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             AVP Code                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   AVP Flags   |            AVP Length                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           PB-TNC Header                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                        PB-PA-Message...                       |                                      
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
          </figure>

          <t><list hangIndent="0" style="hanging">
              <t><list hangIndent="3" style="hanging">
                  <t hangText="AVP Code"><vspace blankLines="1" /> The TTLS NEA AVP type code:
                  <vspace blankLines="1" /><list>
                      
                    <t hangText="TBD"></t>

                    </list><vspace blankLines="1" /></t>
		    
		    <t hangText="AVP Flags"><vspace blankLines="1" /> The AVP flags are set to 0.
                  <vspace blankLines="1" /><vspace blankLines="1" /></t>
		    
                  <t hangText="AVP Length"><vspace blankLines="1" />The length of
                  the AVP in octets.<vspace blankLines="1" /></t>

                  <t hangText="PB-TNC Header"><vspace blankLines="1" /> The PB-TNC
                    encapsulation header as described in <xref target="RFC5793"></xref>.</t>
                
                <t hangText="PB-PA Message"><vspace blankLines="1" /> The message between the
                  Posture Broker Client and Posture Broker Server as described in 
                  <xref target="RFC5793"></xref>.</t>
		</list></t></list></t> 
	  </section>
	</section> 

	  </section>

 <section anchor="channelbind" title="Binding the PA exchange to the TLS Tunnel">
<t> Some implementations of the NEA system allow for the external validation of the data collected and sent by the posture collector.  In these cases, an external measurement agent (EMA) signs the data sent by the collector.  In order to prevent posture data of the endpoint from being used on another machine, the TLS tunnel and the posture data signed by the EMA must be bound together.  This is done using the "tls-unique" channel binding defined in <xref target="RFC5929">RFC 5929</xref>.  The data from the first TLS Finished message sent on the most recent TLS connection handshake is included in the data signed by the EMA.  The PA attributes used are specific to the EMA used by the posture collector.  </t>

<t>The "tls-unique" channel-binding data can be used whenever a TLS transport is provided, including TLS over TCP and TLS used in tunnel EAP methods.  It is RECOMMENDED that posture collectors that support an EMA provide a PA attribute to carry the "tls-unique" channel binding data.  The channel binding data MAY be combined with other data using a cryptographic hash or similar technique.  The channel binding attribute MUST be signed by the EMA.  Posture validators that receive channel binding data MUST verify that it is consistent with the channel binding data obtained from the server-side of the TLS connection.</t>
</section>

  <section anchor="Security" title="Security Considerations">
    <t>The NEA TLV container carries network endpoint assessment information between
      the Posture Broker Client and the Posture Broker Server.  As some of this data can be sensitive, 
      TLS cipher suites that provide encryption are RECOMMENDED.</t>

    <t> To address the potential man-in-the-middle attack similar to the Asokan attack described in <xref target="I-D.salowey-nea-asokan" /> the channel binding mechanism defined in <xref target="channelbind" /> SHOULD be used whenever an EMA is available to sign the posture data.  </t>

  </section>

  
  <section anchor="IANA" title="IANA Considerations">
<t>IANA is requested to assign a TCP port number in the "Registered Port" range with the keyword "pt-tcp". This port will be the default port for PT-TCP defined in this document.</t>
    <t>IANA is requested to allocate a TLV type from the EAP-FAST TLV Type registry for carrying posture data as specified in <xref target="eap-fast" />.</t>
<t>IANA is requested to allocate a Diameter AVP code from the Diameter AVP code registry for carrying posture data as specified in <xref target="ttls" />. </t>
<t>This document defines a registry for TLV types to be carried within PT-TCP, which may be
assigned by Specification Required as defined in <xref target="RFC2434" /> </t>

  </section>

    <section title="Acknowledgements">
      <t>The authors would like to recognize Susan Thomson,
        Syam Appala and Subbu Srinivasan for providing input into this draft.</t>
    </section>
  
</middle>

<!-- BACK MATTER *** -->
  
 <back>
   <references title="Normative References">
     &RFC2119;
     &RFC2434;
     &RFC3748;
     &RFC4493;
     &RFC5929;
     &RFC5793;
     &RFC4422;
   </references>
   <references title="Informative References">
 &salowey-nea-asokan; 
</references>

<section anchor="reqmts" title="Evaluation Against NEA Requirements">
<t> This section evaluates both the PT-TCP and EAP based protocols against
the PT requirements defined in the NEA Overview and Requirements and PB-TNC specifications.
</t>
      <section title="Evaluation Against Requirement C-1">
	<t> Requirement C-1 states: </t>
	<t>C-1  NEA protocols MUST support multiple round trips between the NEA Client and the NEA Server in a single assessment. </t>
	<t> PT-TCP meets this requirement.  By using the TLS protocol over TCP, multiple roundtrips of TLS records and thus PT-TCP messages are allowed.</t>
	<t> Tunnel EAP meets this requirement.  All available Tunnel EAP methods are based on the TLS design which allows for multiple round trips. </t>
      </section>

      <section title="Evaluation Against Requirement C-2">
	<t> Requirement C-2 states: </t>
	<t>C-2  NEA protocols SHOULD provide a way for both the NEA Client and the NEA Server to initiate a posture assessment or reassessment as needed. </t>
	<t> PT-TCP meets this requirement.  PT-TCP allows either the NEA Client or the NEA Server to initiate an assessment or reassessment.</t>
	<t> Tunnel EAP does not meet this requirement.  The typical use case scenario for using a Tunnel EAP method is to service the layer 2 network stack.  In this use case, the endpoint would not have an IP address yet as it is requesting network access and thus would not be able to accept requests from the NEA Server.  However, once network access has been granted, then yes, the NEA Client could receive (re)assessment requests from the NEA Server.</t>
      </section>

      <section title="Evaluation Against Requirement C-3">
	<t> Requirement C-3 states: </t>
	<t>C-3  NEA protocols including security capabilities MUST be capable of protecting against active and passive attacks by intermediaries and endpoints including prevention from replay based attacks. </t>
	<t> PT-TCP meets this requirement.  TLS includes mechanisms that provide strong cryptographic authentication, message integrity and confidentiality for NEA. In addition, to further mitigate man-in-the middle attacks, the use of channel binding at the PA layer must be used.</t>
	<t> Tunnel EAP meets this requirement.  All available Tunnel EAP methods are based on the TLS design which provide strong cryptographic authentication, message integrity and confidentiality for NEA. In addition, to further mitigate man-in-the middle attacks, the use of channel binding at the PA layer must be used. </t>
      </section>

      <section title="Evaluation Against Requirement C-4">
	<t> Requirement C-4 states: </t>
	<t>C-4  The PA and PB protocols MUST be capable of operating over any PT protocol. </t>
	<t> This requirement is not applicable to PT, though the PT-TCP protocol is independent
	of both the PA and PB layer.</t>
	<t> This requirement is not applicable to PT, though the Tunnel EAP protocols are independent
	of both the PA and PB layer.</t>
      </section>

      <section title="Evaluation Against Requirement C-5">
	<t> Requirement C-5 states: </t>
	<t>C-5  The selection process for NEA protocols MUST evaluate and prefer the reuse of existing open standards that meet the requirements before defining new ones.  The goal of NEA is not to create additional alternative protocols where acceptable solutions already exist. </t>
	<t> As TLS is a widely used open standard, it should meet this requirement.</t>
	<t> As EMU is still in the early stages of standardizing a Tunnel EAP method, this specification reuses already widely deployed, published Tunnel EAP methods. Rather than defining a new Tunnel EAP method, this specification proposes to adopt already used ones and provides guidance for how new Tunnel EAP methods can meet this criteria to allow for NEA to use the method standardized by EMU at some future date.</t>

      </section>
      <section title="Evaluation Against Requirement C-6">
	<t> Requirement C-6 states: </t>
	<t>C-6  NEA protocols MUST be highly scalable; the protocols MUST support many Posture Collectors on a large number of NEA Clients to be assessed by numerous Posture Validators residing on multiple NEA Servers. </t>
	<t> PT-TCP meets this requirement.  As PT-TCP is a protocol to establish a protected channel by which NEA data can be transported, it is independent of the content of the data it is transporting and thus can allow for carrying batches of data to multiple Posture Validators or Posture Collectors.</t>
	<t> Tunnel EAP methods meet this requirement.  As the Tunnel EAP methods define a protected transport channel that is independent of the content it transports, it can carry batches of data from and to multiple Posture Collectors and Posture Validators.</t>
      </section>

      <section title="Evaluation Against Requirement C-7">
	<t> Requirement C-7 states: </t>
	<t>C-7  The protocols MUST support efficient transport of a large number of attribute messages between the NEA Client and the NEA Server. </t>
	<t> PT-TCP meets this requirement.  The PT-TCP usurps 6 octets of overhead per PT-TCP message; a small overhead to the ability to carry very many PA-TNC attributes within a PB-TNC batch.</t>
	<t> The Tunnel EAP methods meet this requirements subject to the limitations of the underlying EAP protocol and encapsulation mechanisms. Note that a typical use case for the Tunnel EAP methods is that the assessments are brief and used for enabling network access; as such, it is not recommended to use Tunnel EAP methods to carry large amounts of attributes.</t>
      </section>

      <section title="Evaluation Against Requirement C-8">
	<t> Requirement C-8 states: </t>
	<t>C-8 NEA protocols MUST operate efficiently over low bandwidth or high latency links. </t>
	<t> PT-TCP meets this requirement.  As TLS was originally designed to work at the TCP layer, it has been proven to work well over either low bandwidth or high latency links.</t>
	<t> EAP Tunnel methods meet this requirement.  The underlying EAP framework was designed and proven to work under constrained and low latency links.</t>
      </section>

      <section title="Evaluation Against Requirement C-9">
	<t> Requirement C-9 states: </t>
	<t>C-9 For any strings intended for display to a user, the protocols MUST support adapting these strings to the user's language preferences. </t>
	<t> PT-TCP meets this requirement.  The PT-TCP protocol does not define messages intended for display to the user.</t>
	<t> EAP Tunnel methods meet this requirement.  The EAP Tunnel methods do not define messages intended for display to the user. </t>
      </section>

      <section title="Evaluation Against Requirement C-10">
	<t> Requirement C-10 states: </t>
	<t>C-10 NEA protocols MUST support encoding of strings in UTF-8 format. </t>
	<t> PT-TCP meets this requirement.  The PT-TCP protocol does not define messages intended for display to the user.</t>
	<t> EAP Tunnel methods meet this requirement.  The EAP Tunnel methods do not define messages intended for display to the user. </t>
      </section>

      <section title="Evaluation Against Requirement C-11">
	<t> Requirement C-11 states: </t>
	<t>C-11 Due to the potentially different transport characteristics provided by the underlying candidate PT protocols, the NEA Client and the NEA Server MUST be capable of becoming aware of and adapting to the limitations of the available PT protocol. </t>
	<t> PT-TCP meets this requirement.  The PT-TCP protocol uses TLS which is designed to provide reliable transport that can adapt to constrained or low bandwidth links.</t>
	<t> EAP Tunnel methods meet this requirement.  The EAP Tunnel methods are based on TLS which is designed to provide reliable transport and have been proven to adapt and work well under high latency or low bandwidth conditions. </t>
      </section>

      <section title="Evaluation Against Requirement PT-1">
	<t> Requirement PT-1 states: </t>
	<t>PT-1 The PT protocol MUST NOT interpret the contents of PB messages being transported, i.e., the data it is carrying must be opaque to it. </t>
	<t> PT-TCP meets this requirement.  The PT-TCP protocol encapsulates PB messages in a TLV container without interpreting their contents.</t>
	<t> EAP Tunnel methods meet this requirement.  The EAP Tunnel methods define encapsulations for carrying arbitrary data without interpreting their contents. </t>
      </section>

      <section title="Evaluation Against Requirement PT-2">
	<t> Requirement PT-2 states: </t>
	<t>PT-2 The PT protocol MUST be capable of supporting mutual authentication, integrity, confidentiality, and replay protection of the PB messages between the Posture Transport Client and the Posture Transport Server. </t>
	<t> PT-TCP meets this requirement.  The PT-TCP protocol uses TLS to provide mutual authentication, integrity, confidentiality, and replay protection.</t>
	<t> EAP Tunnel methods meet this requirement.  The EAP Tunnel methods are based on TLS which is designed to provide  mutual authentication, integrity, confidentiality, and replay protection. </t>
      </section>

      <section title="Evaluation Against Requirement PT-3">
	<t> Requirement PT-3 states: </t>
	<t>PT-3 The PT protocol MUST provide reliable delivery for the PB protocol.  This includes the ability to perform fragmentation and reassembly, detect duplicates, and reorder to provide in-sequence delivery, as required. </t>
	<t> PT-TCP meets this requirement.  The PT-TCP protocol is designed to work over TCP which provides the fragmentation and reassembly services, detect duplicates and reorder messages if they arrive out of order.</t>
	<t> EAP Tunnel methods meet this requirement.  The EAP Tunnel methods are based on the EAP framework which provides retransmissions, while reordering and fragmentation are handled by the individual EAP Tunnel methods. </t>
      </section>

      <section title="Evaluation Against Requirement PT-4">
	<t> Requirement PT-4 states: </t>
	<t>PT-4 The PT protocol SHOULD be able to run over existing network access protocols such as 802.1X and IKEv2. </t>
	<t> PT-TCP does NOT meet this requirement as it is designed to operate over TCP.</t>
	<t> EAP Tunnel methods meet this requirement.  The EAP Tunnel methods are based on EAP which has been enabled on both 802.1X and IKEv2.</t>
      </section>

      <section title="Evaluation Against Requirement PT-5">
	<t> Requirement PT-5 states: </t>
	<t>PT-5 The PT protocol SHOULD be able to run between a NEA Client and NEA Server over TCP or UDP (similar to Lightweight Directory Access Protocol (LDAP))</t>
	<t> PT-TCP meets this requirement.  The PT-TCP protocol is designed to operate over a TCP connection.</t>
	<t> EAP Tunnel methods do NOT meet this requirement.  The EAP Tunnel methods are designed to work pre-network admission and thus are not able to communicate at the IP layer. </t>
      </section>

      <section title="Evaluation Against Requirement PT-6">
	<t> Requirement PT-6 states: </t>
	<t>PT-6 The PT protocol MUST be connection oriented; it MUST support confirmed initiation and close down. </t>
	<t> PT-TCP meets this requirement.  The PT-TCP protocol is designed to operate over a TCP connection which is connection oriented and supports initiation and tear down of the connection.</t>
	<t> EAP Tunnel methods meet this requirement.  The EAP Tunnel methods are based on EAP which provides both initiation and shutdown. </t>
      </section>

      <section title="Evaluation Against Requirement PT-7">
	<t> Requirement PT-7 states: </t>
	<t>PT-7 The PT protocol MUST be able to carry binary data. </t>
	<t> PT-TCP meets this requirement.  The PT-TCP protocol is capable of carrying binary data.</t>
	<t> EAP Tunnel methods meet this requirement.  The EAP Tunnel methods are capable of carrying binary data.</t>
      </section>

      <section title="Evaluation Against Requirement PT-8">
	<t> Requirement PT-8 states: </t>
	<t>PT-8 The PT protocol MUST provide mechanisms for flow control and congestion control. </t>
	<t> PT-TCP meets this requirement.  The PT-TCP protocol operates over TCP which provides flow control and congestion control.</t>
	<t> EAP Tunnel methods meet this requirement.  The EAP Tunnel methods are based on EAP which, by use of the half-duplex, round-robin message exchange, flow and congestion control are provided.</t>
      </section>

      <section title="Evaluation Against Requirement PT-9">
	<t> Requirement PT-9 states: </t>
	<t>PT-9 The PT protocol specifications MUST describe the capabilities that they provide for and limitations that they impose on the PB protocol (e.g. half/full duplex, maximum message size). </t>
	<t> PT-TCP meets this requirement.  This specification has provided the required information.</t>
	<t> EAP Tunnel methods meet this requirement.  This specification has provided the required information.</t>
      </section>
    </section>
  </back>
</rfc>