[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Network Working Group                                      N. Cam-Winget
Internet-Draft                                                J. Salowey
Intended status: Standards Track                                 H. Zhou
Expires: September 8, 2011                                 Cisco Systems
                                                           March 7, 2011


  Transport Layer Security (TLS) Based Transports for Network Endpoint
                  Assessment (NEA) Protocol Exchanges
                      draft-cam-winget-eap-tlv-03

Abstract

   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.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 8, 2011.

Copyright Notice

   Copyright (c) 2011 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



Cam-Winget, et al.      Expires September 8, 2011               [Page 1]


Internet-Draft          TLS Based NEA Transports              March 2011


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Specification Requirements . . . . . . . . . . . . . . . . . .  4
   3.  Protocol Layering Model  . . . . . . . . . . . . . . . . . . .  4
   4.  Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  PT-TCP Protocol Flow . . . . . . . . . . . . . . . . . . .  5
       4.1.1.  Initiating a PT-TCP session  . . . . . . . . . . . . .  5
       4.1.2.  TCP Port Usage . . . . . . . . . . . . . . . . . . . .  5
       4.1.3.  TLS Setup Phase  . . . . . . . . . . . . . . . . . . .  5
       4.1.4.  NEA Data Transport Phase in PT-TCP . . . . . . . . . .  6
       4.1.5.  Entity Authentication using SASL in PT-TCP . . . . . .  6
         4.1.5.1.  Service Name . . . . . . . . . . . . . . . . . . .  7
         4.1.5.2.  Mechanism Negotiation  . . . . . . . . . . . . . .  7
         4.1.5.3.  Message Definition . . . . . . . . . . . . . . . .  7
         4.1.5.4.  Authorization Identity . . . . . . . . . . . . . .  7
         4.1.5.5.  Aborting Authentication  . . . . . . . . . . . . .  7
         4.1.5.6.  Security Layers  . . . . . . . . . . . . . . . . .  7
         4.1.5.7.  Multiple Authentications . . . . . . . . . . . . .  7
     4.2.  Tunnel EAP Message Flow  . . . . . . . . . . . . . . . . .  8
   5.  Packet Formats . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.1.  PT-TCP transport Format  . . . . . . . . . . . . . . . . .  9
       5.1.1.  NEA TLV  . . . . . . . . . . . . . . . . . . . . . . . 10
       5.1.2.  SASL-MECH TLV  . . . . . . . . . . . . . . . . . . . . 11
       5.1.3.  SASL-AUTH TLV  . . . . . . . . . . . . . . . . . . . . 12
       5.1.4.  SASL-RESULT TLV  . . . . . . . . . . . . . . . . . . . 13
     5.2.  Using tunnel EAP to transport NEA data . . . . . . . . . . 14
       5.2.1.  Carrying NEA data in PEAP or EAP-FAST  . . . . . . . . 14
       5.2.2.  Carrying NEA data in TTLS  . . . . . . . . . . . . . . 16
   6.  Binding the PA exchange to the TLS Tunnel  . . . . . . . . . . 17
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17



Cam-Winget, et al.      Expires September 8, 2011               [Page 2]


Internet-Draft          TLS Based NEA Transports              March 2011


   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
     10.2. Informative References . . . . . . . . . . . . . . . . . . 18
   Appendix A.  Evaluation Against NEA Requirements . . . . . . . . . 19
     A.1.  Evaluation Against Requirement C-1 . . . . . . . . . . . . 19
     A.2.  Evaluation Against Requirement C-2 . . . . . . . . . . . . 19
     A.3.  Evaluation Against Requirement C-3 . . . . . . . . . . . . 19
     A.4.  Evaluation Against Requirement C-4 . . . . . . . . . . . . 20
     A.5.  Evaluation Against Requirement C-5 . . . . . . . . . . . . 20
     A.6.  Evaluation Against Requirement C-6 . . . . . . . . . . . . 21
     A.7.  Evaluation Against Requirement C-7 . . . . . . . . . . . . 21
     A.8.  Evaluation Against Requirement C-8 . . . . . . . . . . . . 21
     A.9.  Evaluation Against Requirement C-9 . . . . . . . . . . . . 22
     A.10. Evaluation Against Requirement C-10  . . . . . . . . . . . 22
     A.11. Evaluation Against Requirement C-11  . . . . . . . . . . . 22
     A.12. Evaluation Against Requirement PT-1  . . . . . . . . . . . 23
     A.13. Evaluation Against Requirement PT-2  . . . . . . . . . . . 23
     A.14. Evaluation Against Requirement PT-3  . . . . . . . . . . . 23
     A.15. Evaluation Against Requirement PT-4  . . . . . . . . . . . 24
     A.16. Evaluation Against Requirement PT-5  . . . . . . . . . . . 24
     A.17. Evaluation Against Requirement PT-6  . . . . . . . . . . . 24
     A.18. Evaluation Against Requirement PT-7  . . . . . . . . . . . 25
     A.19. Evaluation Against Requirement PT-8  . . . . . . . . . . . 25
     A.20. Evaluation Against Requirement PT-9  . . . . . . . . . . . 25
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25

























Cam-Winget, et al.      Expires September 8, 2011               [Page 3]


Internet-Draft          TLS Based NEA Transports              March 2011


1.  Introduction

   NEA has standardized a transport agnostic Posture Broker (PB)
   protocol defined in [RFC5793] 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.


2.  Specification Requirements

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


3.  Protocol Layering Model

   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:


    +---------------------------------------------------------------+
    |          TLV Encapsulation of PB-PA message                   |
    |---------------------------------------------------------------|
    |                         TLS                                   |
    |---------------------------------------------------------------|
    |                EAP tunnel based method                      |
    |---------------------------------------------------------------|
    |                         EAP                                   |
    |---------------------------------------------------------------|
    |        Carrier Protocol (EAPOL, RADIUS, Diameter, etc.)       |
    +---------------------------------------------------------------+


                     EAP based Protocol Layering Model

   The following diagram demonstrates the protocol relationship of PB
   when PT-TCP is used:







Cam-Winget, et al.      Expires September 8, 2011               [Page 4]


Internet-Draft          TLS Based NEA Transports              March 2011


    +---------------------------------------------------------------+
    |           TLV Encapsulation of PB-PA message                  |
    |---------------------------------------------------------------|
    |                         TLS                                   |
    +---------------------------------------------------------------+
    |                         TCP                                   |
    +---------------------------------------------------------------+


                   PT-TCP based Protocol Layering Model


4.  Protocol Flows

   There are two distinct phases in TLS based transport operation:

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

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

4.1.  PT-TCP Protocol Flow

   This section describes the general flow of messages between the NEA
   Posture Transport Client and the NEA Posture Transport Server.

4.1.1.  Initiating a PT-TCP session

   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.

4.1.2.  TCP Port Usage

   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.

4.1.3.  TLS Setup Phase

   Typically, it is the NEA Client (e.g. the Posture Transport Client)
   that initiates the TLS Setup Phase.  However, either party, e.g. the



Cam-Winget, et al.      Expires September 8, 2011               [Page 5]


Internet-Draft          TLS Based NEA Transports              March 2011


   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.

   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.

4.1.4.  NEA Data Transport Phase in PT-TCP

   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 Section 5.1.

   As PT-TCP is full-duplex (by the TLS design), it supports the full
   capabilities of the PB-TNC state machine.

4.1.5.  Entity Authentication using SASL in PT-TCP

   Implementations may support entity authentication through the use of
   SASL [RFC4422].  This section details the SASL profile for PT-TCP.

   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.

   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



Cam-Winget, et al.      Expires September 8, 2011               [Page 6]


Internet-Draft          TLS Based NEA Transports              March 2011


   ABORT result code.

   Implementations MUST provide the EXTERNAL SASL mechanism if the
   initiator is authenticated during the TLS establishment.
   Implementations MUST also support the PLAIN SASL mechanism.

4.1.5.1.  Service Name

   The service name for PT-TCP is "nea-pt-tcp".

4.1.5.2.  Mechanism Negotiation

   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.

4.1.5.3.  Message Definition

   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.

4.1.5.4.  Authorization Identity

   The nea-pt-tcp protocol does not make use of an authorization
   identity.

4.1.5.5.  Aborting Authentication

   The initiator may abort the authentication exchange by sending the
   SASL-AUTH-RESULT TLV with a status code of ABORT.

4.1.5.6.  Security Layers

   The NEA PT-TCP protocol always runs under the protection of TLS.
   SASL security layers are not used.

4.1.5.7.  Multiple Authentications

   Only one authentication may be in progress at any one time.  Once an
   authentication completes, successfully on unsuccessfully, a new
   authentication may be initiated.




Cam-Winget, et al.      Expires September 8, 2011               [Page 7]


Internet-Draft          TLS Based NEA Transports              March 2011


4.2.  Tunnel EAP 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 when using a
   tunnel EAP method.

   When NEA data exchange is conducted in a tunnel EAP method, it
   typically consists of four phases:

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

   2.  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).

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

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

   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.


5.  Packet Formats

   As there is no explicit authentication expected in the PB-PA message
   exchanges, no new inner EAP method is required; rather, the TLV



Cam-Winget, et al.      Expires September 8, 2011               [Page 8]


Internet-Draft          TLS Based NEA Transports              March 2011


   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.

5.1.  PT-TCP transport Format

   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.

    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                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




      R

         Reserved, set to zero (0)


   TLV Type

      TLV Type Code.  Allocated Types include:


      0  Reserved

      1  NEA TLV

      2  SASL-MECH TLV

      3  SASL-AUTH TLV

      4  SASL-RESULT TLV






Cam-Winget, et al.      Expires September 8, 2011               [Page 9]


Internet-Draft          TLS Based NEA Transports              March 2011


   Length

      The length of the Data field in octets.


   Data

      Data according to the TLV type.

5.1.1.  NEA TLV

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




      R

         Reserved, set to zero (0)


   TLV Type

      1 for NEA TLV


   Length

      The length of the Value field in octets.


   PB-TNC Header

      The PB-TNC encapsulation header as described in [RFC5793].







Cam-Winget, et al.      Expires September 8, 2011              [Page 10]


Internet-Draft          TLS Based NEA Transports              March 2011


   PB-PA Message

      The message between the Posture Broker Client and Posture Broker
      Server as described in [RFC5793].

5.1.2.  SASL-MECH TLV

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





   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.



      R

         Reserved, set to zero (0)


   TLV Type

      2 for SASL-MECH TLV


   Length

      The length of the Value field in octets.  The value field contains
      the list of mechanism names.




Cam-Winget, et al.      Expires September 8, 2011              [Page 11]


Internet-Draft          TLS Based NEA Transports              March 2011


   Mech-Name-Length

      Length of the mechanism name in bytes.

   Mech-Name

      SASL mechanism Name adhering to the rules defined in [RFC4422].

5.1.3.  SASL-AUTH TLV


    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                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   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.



      R

         Reserved, set to zero (0)









Cam-Winget, et al.      Expires September 8, 2011              [Page 12]


Internet-Draft          TLS Based NEA Transports              March 2011


   TLV Type

      3 for SASL-AUTH TLV


   Length

      The length of the Value field in octets.  The value field contains
      a mechanism name and optional mechanism data..


   Mech-Name-Length

      Length of the mechanism name in bytes.

   Mech-Name

      SASL mechanism Name adhering to the rules defined in [RFC4422].
      This is the mechanism selected for use by the initiator.

   Mech-Name

      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.

5.1.4.  SASL-RESULT TLV



    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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   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.




Cam-Winget, et al.      Expires September 8, 2011              [Page 13]


Internet-Draft          TLS Based NEA Transports              March 2011




      R

         Reserved, set to zero (0)


   TLV Type

      4 for SASL-Result TLV


   Length

      The length of the Value field in octets.  This field is set to 2.


   Result Code

      The value of the result code.


      0  Success

      1  Abort

      2  Mechanism Failure


5.2.  Using tunnel EAP to transport NEA data

   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.

5.2.1.  Carrying NEA data in PEAP or EAP-FAST

   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.










Cam-Winget, et al.      Expires September 8, 2011              [Page 14]


Internet-Draft          TLS Based NEA Transports              March 2011


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




      M


         0  Optional TLV

         1  Mandatory TLV


      R

         Reserved, set to zero (0)


      TLV Type

         The EAP-FAST NEA TLV type:


         TBD


      Length

         The length of the Value field in octets.


      PB-TNC Header

         The PB-TNC encapsulation header as described in [RFC5793].

      PB-PA Message

         The message between the Posture Broker Client and Posture
         Broker Server as described in [RFC5793].




Cam-Winget, et al.      Expires September 8, 2011              [Page 15]


Internet-Draft          TLS Based NEA Transports              March 2011


5.2.2.  Carrying NEA data in TTLS

   The TTLS AVP Format to carry PB-PA messages is defined and described
   below.  The fields are transmitted from left to right.

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




      AVP Code

         The TTLS NEA AVP type code:


         TBD


      AVP Flags

         The AVP flags are set to 0.



      AVP Length

         The length of the AVP in octets.


      PB-TNC Header

         The PB-TNC encapsulation header as described in [RFC5793].

      PB-PA Message

         The message between the Posture Broker Client and Posture
         Broker Server as described in [RFC5793].



Cam-Winget, et al.      Expires September 8, 2011              [Page 16]


Internet-Draft          TLS Based NEA Transports              March 2011


6.  Binding the PA exchange to the TLS Tunnel

   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 RFC 5929 [RFC5929].
   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.

   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.


7.  Security Considerations

   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.

   To address the potential man-in-the-middle attack similar to the
   Asokan attack described in [I-D.salowey-nea-asokan] the channel
   binding mechanism defined in Section 6 SHOULD be used whenever an EMA
   is available to sign the posture data.


8.  IANA Considerations

   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.

   IANA is requested to allocate a TLV type from the EAP-FAST TLV Type
   registry for carrying posture data as specified in Section 5.2.1.




Cam-Winget, et al.      Expires September 8, 2011              [Page 17]


Internet-Draft          TLS Based NEA Transports              March 2011


   IANA is requested to allocate a Diameter AVP code from the Diameter
   AVP code registry for carrying posture data as specified in
   Section 5.2.2.

   This document defines a registry for TLV types to be carried within
   PT-TCP, which may be assigned by Specification Required as defined in
   [RFC2434]


9.  Acknowledgements

   The authors would like to recognize Susan Thomson, Syam Appala and
   Subbu Srinivasan for providing input into this draft.


10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

   [RFC4422]  Melnikov, A. and K. Zeilenga, "Simple Authentication and
              Security Layer (SASL)", RFC 4422, June 2006.

   [RFC4493]  Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
              AES-CMAC Algorithm", RFC 4493, June 2006.

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

10.2.  Informative References

   [I-D.salowey-nea-asokan]
              Salowey, J. and S. Hanna, "NEA Asokan Attack Analysis",
              draft-salowey-nea-asokan-00 (work in progress),



Cam-Winget, et al.      Expires September 8, 2011              [Page 18]


Internet-Draft          TLS Based NEA Transports              March 2011


              October 2010.


Appendix A.  Evaluation Against NEA Requirements

   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.

A.1.  Evaluation Against Requirement C-1

   Requirement C-1 states:

   C-1 NEA protocols MUST support multiple round trips between the NEA
   Client and the NEA Server in a single assessment.

   PT-TCP meets this requirement.  By using the TLS protocol over TCP,
   multiple roundtrips of TLS records and thus PT-TCP messages are
   allowed.

   Tunnel EAP meets this requirement.  All available Tunnel EAP methods
   are based on the TLS design which allows for multiple round trips.

A.2.  Evaluation Against Requirement C-2

   Requirement C-2 states:

   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.

   PT-TCP meets this requirement.  PT-TCP allows either the NEA Client
   or the NEA Server to initiate an assessment or reassessment.

   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.

A.3.  Evaluation Against Requirement C-3

   Requirement C-3 states:

   C-3 NEA protocols including security capabilities MUST be capable of
   protecting against active and passive attacks by intermediaries and



Cam-Winget, et al.      Expires September 8, 2011              [Page 19]


Internet-Draft          TLS Based NEA Transports              March 2011


   endpoints including prevention from replay based attacks.

   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.

   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.

A.4.  Evaluation Against Requirement C-4

   Requirement C-4 states:

   C-4 The PA and PB protocols MUST be capable of operating over any PT
   protocol.

   This requirement is not applicable to PT, though the PT-TCP protocol
   is independent of both the PA and PB layer.

   This requirement is not applicable to PT, though the Tunnel EAP
   protocols are independent of both the PA and PB layer.

A.5.  Evaluation Against Requirement C-5

   Requirement C-5 states:

   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.

   As TLS is a widely used open standard, it should meet this
   requirement.

   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.




Cam-Winget, et al.      Expires September 8, 2011              [Page 20]


Internet-Draft          TLS Based NEA Transports              March 2011


A.6.  Evaluation Against Requirement C-6

   Requirement C-6 states:

   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.

   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.

   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.

A.7.  Evaluation Against Requirement C-7

   Requirement C-7 states:

   C-7 The protocols MUST support efficient transport of a large number
   of attribute messages between the NEA Client and the NEA Server.

   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.

   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.

A.8.  Evaluation Against Requirement C-8

   Requirement C-8 states:

   C-8 NEA protocols MUST operate efficiently over low bandwidth or high
   latency links.

   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.



Cam-Winget, et al.      Expires September 8, 2011              [Page 21]


Internet-Draft          TLS Based NEA Transports              March 2011


   EAP Tunnel methods meet this requirement.  The underlying EAP
   framework was designed and proven to work under constrained and low
   latency links.

A.9.  Evaluation Against Requirement C-9

   Requirement C-9 states:

   C-9 For any strings intended for display to a user, the protocols
   MUST support adapting these strings to the user's language
   preferences.

   PT-TCP meets this requirement.  The PT-TCP protocol does not define
   messages intended for display to the user.

   EAP Tunnel methods meet this requirement.  The EAP Tunnel methods do
   not define messages intended for display to the user.

A.10.  Evaluation Against Requirement C-10

   Requirement C-10 states:

   C-10 NEA protocols MUST support encoding of strings in UTF-8 format.

   PT-TCP meets this requirement.  The PT-TCP protocol does not define
   messages intended for display to the user.

   EAP Tunnel methods meet this requirement.  The EAP Tunnel methods do
   not define messages intended for display to the user.

A.11.  Evaluation Against Requirement C-11

   Requirement C-11 states:

   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.

   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.

   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.




Cam-Winget, et al.      Expires September 8, 2011              [Page 22]


Internet-Draft          TLS Based NEA Transports              March 2011


A.12.  Evaluation Against Requirement PT-1

   Requirement PT-1 states:

   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.

   PT-TCP meets this requirement.  The PT-TCP protocol encapsulates PB
   messages in a TLV container without interpreting their contents.

   EAP Tunnel methods meet this requirement.  The EAP Tunnel methods
   define encapsulations for carrying arbitrary data without
   interpreting their contents.

A.13.  Evaluation Against Requirement PT-2

   Requirement PT-2 states:

   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.

   PT-TCP meets this requirement.  The PT-TCP protocol uses TLS to
   provide mutual authentication, integrity, confidentiality, and replay
   protection.

   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.

A.14.  Evaluation Against Requirement PT-3

   Requirement PT-3 states:

   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.

   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.

   EAP Tunnel methods meet this requirement.  The EAP Tunnel methods are
   based on the EAP framework which provides retransmissions, while



Cam-Winget, et al.      Expires September 8, 2011              [Page 23]


Internet-Draft          TLS Based NEA Transports              March 2011


   reordering and fragmentation are handled by the individual EAP Tunnel
   methods.

A.15.  Evaluation Against Requirement PT-4

   Requirement PT-4 states:

   PT-4 The PT protocol SHOULD be able to run over existing network
   access protocols such as 802.1X and IKEv2.

   PT-TCP does NOT meet this requirement as it is designed to operate
   over TCP.

   EAP Tunnel methods meet this requirement.  The EAP Tunnel methods are
   based on EAP which has been enabled on both 802.1X and IKEv2.

A.16.  Evaluation Against Requirement PT-5

   Requirement PT-5 states:

   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))

   PT-TCP meets this requirement.  The PT-TCP protocol is designed to
   operate over a TCP connection.

   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.

A.17.  Evaluation Against Requirement PT-6

   Requirement PT-6 states:

   PT-6 The PT protocol MUST be connection oriented; it MUST support
   confirmed initiation and close down.

   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.

   EAP Tunnel methods meet this requirement.  The EAP Tunnel methods are
   based on EAP which provides both initiation and shutdown.







Cam-Winget, et al.      Expires September 8, 2011              [Page 24]


Internet-Draft          TLS Based NEA Transports              March 2011


A.18.  Evaluation Against Requirement PT-7

   Requirement PT-7 states:

   PT-7 The PT protocol MUST be able to carry binary data.

   PT-TCP meets this requirement.  The PT-TCP protocol is capable of
   carrying binary data.

   EAP Tunnel methods meet this requirement.  The EAP Tunnel methods are
   capable of carrying binary data.

A.19.  Evaluation Against Requirement PT-8

   Requirement PT-8 states:

   PT-8 The PT protocol MUST provide mechanisms for flow control and
   congestion control.

   PT-TCP meets this requirement.  The PT-TCP protocol operates over TCP
   which provides flow control and congestion control.

   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.

A.20.  Evaluation Against Requirement PT-9

   Requirement PT-9 states:

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

   PT-TCP meets this requirement.  This specification has provided the
   required information.

   EAP Tunnel methods meet this requirement.  This specification has
   provided the required information.












Cam-Winget, et al.      Expires September 8, 2011              [Page 25]


Internet-Draft          TLS Based NEA Transports              March 2011


Authors' Addresses

   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


   Hao Zhou
   Cisco Systems
   4125 Highlander Parkway
   Richfield, OH  44286
   US

   Email: hzhou@cisco.com
























Cam-Winget, et al.      Expires September 8, 2011              [Page 26]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/