[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 draft-ietf-nea-pt-eap

Network Working Group                                          S. Hanna
Internet Draft                                         Juniper Networks
Intended status: Proposed Standard                          P. Sangster
Expires: May 2010                                  Symantec Corporation

                                                        January 4, 2010

      PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods
                      draft-hanna-nea-pt-eap-00.txt


Abstract

   This document specifies PT-EAP, a Posture Broker Protocol identical
   to the Trusted Computing Group's IF-T Protocol Bindings for Tunneled
   EAP Methods (also known as EAP-TNC). The document then evaluates PT-
   EAP against the requirements defined in the NEA Requirements and PB-
   TNC specifications.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on July 4, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors. All rights reserved.





Hanna et al.             Expires July 4, 2010                  [Page 1]

Internet-Draft                  PT-EAP                     January 2010


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Table of Contents

   1. Introduction......................................... 3
      1.1. Prerequisites.................................... 4
      1.2. Message Diagram Conventions........................ 4
      1.3. Terminology..................................... 5
      1.4. Conventions used in this document................... 5
   2. Use of EAP-TNC....................................... 5
   3. Definition of EAP-TNC................................. 5
      3.1. Protocol Overview ................................ 6
      3.2. Version Negotiation............................... 7
      3.3. Fragmentation.................................... 7
      3.4. EAP-TNC Message Format............................ 8
      3.5. Diffie-Hellman (D-H) Pre-Negotiation................ 11
         3.5.1. Use of D Flag............................... 11
         3.5.2. D-H Pre-Negotiation Message Syntax............. 12
            3.5.2.1. D-H PN Hello Request Format............... 12
            3.5.2.2. D-H PN Hello Response Format.............. 12
            3.5.2.3. D-H PN Parameters Request Format........... 13
            3.5.2.4. D-H PN Parameters Response Format.......... 14
         3.5.3. Diffie-Hellman Pre-Negotiation Protocol......... 15
         3.5.4. Diffie-Hellman Pre-Negotiation Hash Algorithm Values18
         3.5.5. Diffie-Hellman Group Values................... 19
            3.5.5.1. Diffie-Hellman Group 1 Definitions......... 19
            3.5.5.2. Diffie-Hellman Group 2 Definitions......... 20
            3.5.5.3. Diffie-Hellman Group 3 Definitions......... 20
   4. Security Considerations............................... 21
      4.1. Trust Relationships.............................. 21
         4.1.1. Posture Transport Client...................... 21
         4.1.2. Posture Transport Server...................... 22
      4.2. Security Threats and Countermeasures................ 23
         4.2.1. Message Theft............................... 24
         4.2.2. Message Fabrication.......................... 24
         4.2.3. Message Modification......................... 25
         4.2.4. Denial of Service........................... 25
         4.2.5. Nested Tunnel Attacks........................ 26
      4.3. Requirements for EAP Tunnel Methods................. 28
      4.4. Candidate EAP Tunnel Method Protections............. 29
      4.5. Security Claims for EAP-TNC as per RFC3748........... 30
   5. Privacy Considerations ............................... 30
   6. IANA Considerations.................................. 31


Hanna                    Expires July 4, 2010                  [Page 2]

Internet-Draft                  PT-EAP                     January 2010


      6.1. Registry for EAP-TNC Versions...................... 31
      6.2. Registry for PT-EAP D-H PN Hash Algorithm IDs ........ 31
      6.3. Registry for PT-EAP D-H PN Group IDs................ 32
   7. References......................................... 32
      7.1. Normative References............................. 32
      7.2. Informative References........................... 33
   8. Acknowledgments..................................... 34
   Appendix A. Evaluation Against NEA Requirements............. 35
      A.1. Evaluation Against Requirement C-1 ................. 35
      A.2. Evaluation Against Requirements C-2................. 35
      A.3. Evaluation Against Requirements C-3................. 35
      A.4. Evaluation Against Requirements C-4................. 36
      A.5. Evaluation Against Requirements C-5................. 36
      A.6. Evaluation Against Requirements C-6................. 36
      A.7. Evaluation Against Requirements C-7................. 37
      A.8. Evaluation Against Requirements C-8................. 37
      A.9. Evaluation Against Requirements C-9................. 37
      A.10. Evaluation Against Requirements C-10............... 38
      A.11. Evaluation Against Requirements C-11............... 38
      A.12. Evaluation Against Requirements PT-1............... 38
      A.13. Evaluation Against Requirements PT-2............... 39
      A.14. Evaluation Against Requirements PT-3............... 39
      A.15. Evaluation Against Requirements PT-4............... 39
      A.16. Evaluation Against Requirements PT-5............... 39
      A.17. Evaluation Against Requirements PT-6 (from PB-TNC
      specification)...................................... 40
      A.18. Evaluation Against Requirements PT-7 (from PB-TNC
      specification)...................................... 40
      A.19. Evaluation Against Requirements PT-8 (from PB-TNC
      specification)...................................... 40
      A.20. Evaluation Against Requirements PT-9 (from PB-TNC
      specification)...................................... 40

1. Introduction

   This document specifies PT-EAP, a Posture Transport Protocol (PT)
   identical to the Trusted Computing Group's IF-T Protocol Bindings for
   Tunneled EAP Methods (also known as EAP-TNC) [12].  The document then
   evaluates PT-EAP against the requirements defined in the NEA
   Requirements [9] and PB-TNC specifications [4].

   The PT protocol in the NEA architecture is responsible for
   transporting PB-TNC batches (often containing PA-TNC [3] attributes)
   across the network between the NEA Client and NEA Server.  The PT
   protocol also offers strong security protections to ensure the
   exchanged messages are protected from a variety of threats from
   hostile intermediaries.


Hanna                    Expires July 4, 2010                  [Page 3]

Internet-Draft                  PT-EAP                     January 2010


   NEA protocols are intended to be used both for pre-admission
   assessment of endpoints joining the network and to assess endpoints
   already present on the network.  In order to support both usage
   models, two types of PT protocols are needed.  One type of PT
   operates after the endpoint has an assigned IP address, layering on
   top of the IP protocol to carry a NEA exchange.  The other type of PT
   operates before the endpoint gains any access to the IP network. This
   specification defines PT-EAP, the PT protocol used to assess
   endpoints before they gain access to the network.

   PT-EAP is comprised of two related protocols, an outer EAP tunnel
   method (not defined in this specification) and an inner EAP method
   that carries the NEA assessment inside the protections of the outer
   EAP tunnel method.  This specification uses the term PT-EAP to refer
   to both collectively.  The inner EAP method is based upon a method
   submitted by the Trusted Computing Group's TNC architecture and
   standards so the inner EAP method is named EAP-TNC.  This
   specification defines the EAP-TNC inner EAP method, while allowing
   the EAP tunnel method to be specified in another specification
   (possibly defined by another IETF WG). The reason to define PT-EAP as
   including both the outer EAP tunnel method and the inner EAP method
   is because both are required to meet the PT requirements.

   EAP-TNC is designed to operate as an inner EAP [10] method over an
   EAP tunnel method that meets the Requirements for a Tunnel Based EAP
   Method [17]. PT-EAP therefore can operate over a number of existing
   access protocols that support EAP for authentication. Some examples
   of such access protocols include 802.1X [7] for wired and wireless
   networks and IKEv2 [15] for establishing VPNs over IP networks.

   This document defines a standard EAP inner method called EAP-TNC.  It
   also shows how EAP-TNC may be carried over two existing EAP tunnel
   EAP methods: EAP-FAST [14] and EAP-TTLS [16].

1.1. Prerequisites

   This document does not define an architecture or reference model.
   Instead, it defines a protocol that works within the reference model
   described in the NEA Requirements specification [9].  The reader is
   assumed to be thoroughly familiar with that document.  No familiarity
   with Trusted Computing Group (TCG) specifications is assumed.

1.2. Message Diagram Conventions

   This specification defines the syntax of EAP-TNC messages using
   diagrams.  Each diagram depicts the format and size of each field in
   bits.  Implementations MUST send the bits in each diagram as they are


Hanna                    Expires July 4, 2010                  [Page 4]

Internet-Draft                  PT-EAP                     January 2010


   shown, traversing the diagram from top to bottom and then from left
   to right within each line (which represents a 32-bit quantity).
   Multi-byte fields representing numeric values must be sent in network
   (big endian) byte order.

   Descriptions of bit field (e.g. flag) values are described referring
   to the position of the bit within the field.  These bit positions are
   numbered from the most significant bit through the least significant
   bit so a one octet field with only bit 0 set has the value 0x80.

1.3. Terminology

   This document reuses many terms defined in the NEA Requirements
   document [9], such as Posture Transport Client and Posture Transport
   Server. The reader is assumed to have read that document and
   understood it.

   When defining the EAP-TNC method, this specification does not use the
   terms "EAP peer" and "EAP authenticator". Instead, it uses the terms
   "NEA Client" and "NEA Server" since those are considered to be more
   familiar to NEA WG participants. However, these terms are equivalent
   for the purposes of these specifications. The part of the NEA Client
   that terminates EAP-TNC (generally in the Posture Transport Client)
   is the EAP peer for EAP-TNC. The part of the NEA Server that
   terminates EAP-TNC (generally in the Posture Transport Server) is the
   EAP authenticator for EAP-TNC.

1.4. Conventions used in this document

   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 RFC 2119 [1].

2. Use of EAP-TNC

   EAP-TNC is designed to encapsulate PB-TNC batches in a simple EAP
   method that can be carried within EAP tunnel methods. The EAP tunnel
   methods provide confidentiality and message integrity, so EAP-TNC
   does not have to do so. Therefore, EAP-TNC MUST only be used inside
   an EAP tunnel method that provides strong cryptographic
   authentication (possibly server only), message integrity and
   confidentiality services.

3. Definition of EAP-TNC

   The EAP-TNC protocol operates between a Posture Transport Client and
   a Posture Transport Server, allowing them to send PB-TNC batches to


Hanna                    Expires July 4, 2010                  [Page 5]

Internet-Draft                  PT-EAP                     January 2010


   each other over an EAP tunnel method. When EAP-TNC is used, the
   Posture Transport Client in the NEA reference model acts as an EAP
   peer (terminating the EAP-TNC method on the endpoint) and the Posture
   Transport Server acts as an EAP authenticator (terminating the EAP-
   TNC method on the NEA Server).

   This section describes and defines the EAP-TNC method. First, it
   provides a protocol overview and a flow diagram. Second, it describes
   specific features like version negotiation and fragmentation. Third,
   it gives a detailed packet description. Finally, it describes the
   Diffie-Hellman Pre-Negotiation (DH-PN) feature, which allows the EAP-
   TNC implementations on the NEA Client and NEA Server to derive a key
   from the EAP-TNC exchange.  This key may be used to cryptographically
   bind the EAP-TNC exchange to the EAP tunnel method, defeating MITM
   attacks.

3.1. Protocol Overview

   EAP-TNC has two phases that follow each other in strict sequence:
   negotiation and data transport.

   The EAP-TNC method begins with the negotiation phase.  The NEA Server
   starts this phase by sending an EAP-TNC Start message: an EAP Request
   message of type EAP-TNC with the S (Start) flag set. The NEA Server
   may set the D flag in the Start message if it wants to engage in
   Diffie-Hellman Pre-Negotiation (D-H PN for short).  If the D flag is
   set, the NEA Client MAY respond by starting D-H PN.  If the NEA
   Client does not support D-H PN or wishes to skip it, the NEA Client
   ignores the D flag and the Start message is the last step in the
   negotiation phase.  If the NEA Client and NEA Server do engage in D-H
   PN, that is the last step in the negotiation phase. In either case,
   the negotiation phase ends with a message from the NEA Server to the
   NEA Client.

   The data transport phase is the only phase of EAP-TNC where PB-TNC
   batches are allowed to be exchanged.  This phase always starts with
   the NEA Client sending a PB-TNC batch to the NEA Server.  The NEA
   Client and NEA Server then engage in a round-robin exchange with one
   PB-TNC batch in flight at a time.  The data transport phase always
   ends with an EAP Response message from the NEA Client to the NEA
   Server.  This message may be empty (not contain any data) if the NEA
   Server has just sent the last PB-TNC batch in the PB-TNC exchange.

   At the end of the EAP-TNC method, the NEA Server will indicate
   success or failure to the EAP tunnel method.  Some EAP tunnel methods
   may provide explicit confirmation of inner method success; others may
   not.  This is out of scope for the EAP-TNC method.  Successful


Hanna                    Expires July 4, 2010                  [Page 6]

Internet-Draft                  PT-EAP                     January 2010


   completion of EAP-TNC does not imply successful completion of the
   overall authentication nor does EAP-TNC failure imply overall
   failure. This depends on the administrative policy in place.

   The NEA Server and NEA Client may engage in an abnormal termination
   of the EAP-TNC exchange at any time by simply stopping the exchange.
   This may also require terminating the EAP tunnel method, depending on
   the capabilities of the EAP tunnel method.

   The NEA Server and NEA Client MUST follow the protocol sequence
   described in this section.

3.2. Version Negotiation

   EAP-TNC version negotiation takes place in the first EAP-TNC message
   sent by the NEA Server (the Start message) and the first EAP-TNC sent
   by the NEA Client (the response to the Start message). The NEA Server
   MUST set the Version field in the Start message to the maximum EAP-
   TNC version that the NEA Server supports and is willing to accept.

   The NEA Client chooses the EAP-TNC version to be used for the
   exchange and places this value in the Version field in its response
   to the Start message. The NEA Client SHOULD choose the value sent by
   the NEA Server if the NEA Client supports it. However, the NEA Client
   MAY set the Version field to a value less than the value sent by the
   NEA Server (for example, if the NEA Client only supports lesser EAP-
   TNC versions). If the NEA Client only supports EAP-TNC versions
   greater than the value sent by the NEA Server, the EAP client MUST
   abnormally terminate the EAP negotiation.

   If the version sent by the NEA Client is not acceptable to the NEA
   Server, the NEA Server MUST terminate the EAP-TNC session
   immediately.  Otherwise, the version sent by the NEA Client is the
   version of EAP-TNC that MUST be used. Both the NEA Client and the NEA
   Server MUST set the Version field to the chosen version number in all
   subsequent EAP-TNC messages in this exchange.

   This specification defines version 1 of EAP-TNC.  Version 0 is
   reserved and MUST never be sent. New versions of EAP-TNC (values 2-7)
   may be defined by Standards Action, as defined in RFC 5226 [8].

3.3. Fragmentation

   In most cases, EAP-TNC fragmentation will not be required. But PB-TNC
   batches can be very long and EAP message length is sometimes tightly
   constrained so EAP-TNC includes a fragmentation mechanism to be used



Hanna                    Expires July 4, 2010                  [Page 7]

Internet-Draft                  PT-EAP                     January 2010


   when a particular PB-TNC batch is too long to fit into a single EAP-
   TNC message.

   The fragmentation mechanism used in EAP-TNC is quite similar to the
   mechanism used by EAP-TLS [18], EAP-TTLS, and EAP-FAST [14]. It uses
   the L flag (length included) and the M flag (more fragments) as well
   as the Data Length field.

   A party (NEA Client or NEA Server) that needs to fragment a long PB-
   TNC batch SHOULD break the batch into pieces (called "fragments")
   that will fit into EAP-TNC messages. Then this party sends the
   fragments in proper sequence, one fragment per EAP-TNC message.  The
   receiving party recognizes the fragments and holds them for
   reassembly, sending an acknowledgment for each fragment so that the
   next fragment can be sent (since EAP only allows one message in
   flight and is half duplex).

   The EAP-TNC message that contains the first fragment MUST have the L
   flag set to indicate that fragmentation is being initiated. This
   packet also MUST contain the Data Length field, indicating the total
   octet length of the unfragmented batch and allowing the party
   receiving the fragments to know how much data will eventually be
   coming. The L flag MUST NOT be set and the Data Length field MUST NOT
   be present in any EAP-TNC message unless that message contains the
   first fragment of a fragmented PB-TNC batch. The M flag MUST be set
   on all but the last fragment and MUST NOT be set on the last
   fragment.

   A party that receives an EAP-TNC message with the M flag set MUST
   respond with an EAP-TNC Acknowledgement message: an EAP-TNC message
   with no Data and with the L, M, and S flags set to 0. The party that
   sent an EAP-TNC message with the M flag set MUST wait for the EAP-TNC
   Acknowledgement packet before sending the next fragment.

   EAP-TNC authenticators and NEA Clients MUST include support for EAP-
   TNC fragmentation with Data Lengths up to 100,000 octets.  However, a
   NEA Server or peer still MAY decide to terminate an EAP-TNC exchange
   at any time for a variety of reasons.

3.4. EAP-TNC Message Format

   This section provides a detailed description of the fields in an EAP-
   TNC message.  For a description of the diagram conventions used here,
   see section 1.2.  Since EAP-TNC is an EAP method, the first four
   fields in each message are mandated by and defined in EAP.




Hanna                    Expires July 4, 2010                  [Page 8]

Internet-Draft                  PT-EAP                     January 2010


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |   Identifier  |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type       |   Flags | Ver |     Data Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Data Length           |           Data ...            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Code

      The Code field is one octet and identifies the type of the EAP
      message. The only values used for EAP-TNC are:

      1 - Request

      2 - Response

   Identifier

      The Identifier field is one octet and aids in matching Responses
      with Requests.

   Length

      The Length field is two octets and indicates the length in octets
      of this EAP-TNC message, starting from the Code field.  If an EAP-
      TNC message has been fragmented, the Length field will cover only
      this fragment and thus doesn't reflect the overall length of the
      entire unfragmented EAP-TNC message.

   Type

      38

      [IANA Note: This value was previously reserved for another purpose
      but has been used for EAP-TNC for some time and never used for the
      other purpose so please assign this value to EAP-TNC.]

   Flags

      +-+-+-+-+-+
      |L M S D R|
      +-+-+-+-+-+




Hanna                    Expires July 4, 2010                  [Page 9]

Internet-Draft                  PT-EAP                     January 2010


   L: Length included

      Indicates the presence of the Data Length field in the EAP-TNC
      message. This flag MUST be set for an EAP-TNC message that
      contains the first fragment of a fragmented EAP-TNC message and
      only for such a message. This flag MUST NOT be set for non-
      fragmented messages.

   M: More fragments

      Indicates that more fragments are to follow. This flag MUST be set
      for all EAP-TNC messages that contain a fragmented EAP-TNC message
      except that this bit MUST NOT be set for EAP-TNC messages that
      contain the last fragment of a fragmented message. This flag MUST
      NOT be set for EAP-TNC messages that contain unfragmented Data.

   S: Start

      Indicates the beginning of an EAP-TNC exchange. This flag MUST be
      set only for the first message from the NEA Server. If the S flag
      is set, the EAP message MUST NOT contain Data or have the L or M
      flags set.

   D: Diffie-Hellman Pre-Negotiation

      Indicates the use of a Diffie-Hellman (D-H) based exchange to
      provide key derivation.  See section 3.6 for specifics of when to
      set this flag and how to handle it.

   R: Reserved

      This flag MUST be set to 0 and ignored upon receipt.

   Version

      This field is used for version negotiation, as described in
      section 3.2.

   Data Length

      Data Length is an optional field four octets in length. It MUST be
      present if and only if the L flag is set. When present, it
      indicates the total length, before fragmentation, of a fragmented
      PB-TNC batch. The Data Length field MUST be set in the EAP-TNC
      message that contains the first in a series of fragments and MUST
      NOT be set in subsequent fragments.



Hanna                    Expires July 4, 2010                 [Page 10]

Internet-Draft                  PT-EAP                     January 2010


   Data

      Variable length data. The length of the Data field in a particular
      EAP-TNC message may be determined by subtracting the length of the
      EAP-TNC header fields from the value of the two octet Length
      field. Note, however, that this data may only be part of a longer
      fragmented PB-TNC batch conveyed in multiple EAP-TNC messages.

3.5. Diffie-Hellman (D-H) Pre-Negotiation

   This section describes the optional Diffie-Hellman Pre-Negotiation
   feature of EAP-TNC (known as D-H PN).  The D-H PN feature allows the
   EAP-TNC implementations on the NEA Client and NEA Server to derive a
   key from the EAP-TNC exchange.  This key may be used to
   cryptographically bind the EAP-TNC exchange to the EAP tunnel method,
   defeating MITM attacks such as those described in section 4.2.5.

   All EAP-TNC implementations on NEA Servers MUST support D-H PN.  EAP-
   TNC implementations on NEA Clients MAY support D-H PN.  However,
   administrative configuration and policy SHOULD determine whether this
   feature is disabled, permitted, or required.

   D-H PN was designed to enable it to be added without causing backward
   compatibility issues.  Legacy clients only supporting IF-T Protocol
   Bindings for Tunneled EAP Methods 1.0 are required to ignore the use
   of the D flag. D-H PN was added in version 1.1 of that protocol.  As
   a result the NEA Server (which initiates a D-H PN request) can not
   assume the Posture Transport Client will support DH-PN.  Therefore
   the Posture Transport Server MUST wait until the Posture Transport
   Client has sent a message indicating it supports D-H PN (D flag set)
   before sending messages with the D-H PN described below.  This
   decision causes a full roundtrip to occur prior to exchanging D-H PN
   messages.

3.5.1. Use of D Flag

   The use of the "D" flag in the EAP-TNC header MUST follow very strict
   rules described in Section 3.4.  If the D flag is one (1), this
   indicates the data field of the EAP-TNC message MUST only contain the
   pre-negotiation information or be empty (as in the initial exchange
   messages) and not contain PB-TNC batches.  PB-TNC batches MUST NOT be
   included in messages with the D flag set to one (1).  Either entity
   MAY set the D flag to 0 at any time indicating it does not wish to
   (or is incapable of) perform the D-H PN exchange.  The other party
   MAY then determine whether to proceed with the dialog without a D-H
   PN exchange.



Hanna                    Expires July 4, 2010                 [Page 11]

Internet-Draft                  PT-EAP                     January 2010


3.5.2. D-H Pre-Negotiation Message Syntax

   This section describes the format of the data field within each of
   the four D-H PN messages exchanged.  These messages are only present
   in the data field when the D flag is set to one. The D flag MUST be
   set for all D-H PN messages.  If the NEA Client or NEA Server
   receives a message with the D flag set to zero in the middle of a D-H
   PN exchange, it SHOULD interpret this as meaning that the sender has
   decided to terminate the D-H PN exchange but would like to proceed
   with the NEA exchange. The recipient MAY proceed or terminate the
   entire NEA exchange.  The messages are presented in the order they
   would appear in a D-H PN message exchange.

3.5.2.1. D-H PN Hello Request Format

   The data field of the initial D-H PN message from the NEA Server MUST
   be empty for backward compatibility.  This message occurs at the
   start of a session with the start flag set to one and the D flag set
   to one (indicating a desire to initiate D-H PN without sending a data
   field that would be confusing to legacy NEA Clients that might ignore
   the D flag.)

3.5.2.2. D-H PN Hello Response Format

   The data field of the initial response from the Posture Transport
   Client allows a NEA Client to notify the Posture Transport Server
   that it is able and willing to perform a D-H PN (by replying with the
   D flag set to one.)  The defined protocol expects the NEA Server to
   lead the negotiation except for the D-H group which needs to be
   negotiated before the public value exchange can occur (since it
   affects the size.)  In order to reduce the number of messages
   required, this message includes the set of supported/preferred D-H
   groups and any minimum nonce size.

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   D-H Group   | Min. Nonce Len|   Reserved for future use     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   D-H Group

      Flag field indicating the supported D-H groups.  See section
      3.5.5. for description of the D-H groups and their representation
      in this field.  The NEA Client policy MAY dictate what groups are
      allowable for a particular NEA Server.


Hanna                    Expires July 4, 2010                 [Page 12]

Internet-Draft                  PT-EAP                     January 2010


   Min Nonce Len

      NEA Client can send a minimum acceptable length for the nonce in
      bytes.  This value should be set to zero if there is no minimum
      required.

3.5.2.3. D-H PN Parameters Request Format

   This is the data field of the NEA Server's request message trying to
   finalize the negotiation of the parameters of the D-H PN exchange.
   This message proposes the NEA Server's set of supported hash
   algorithms.  The D-H group MUST be selected from the set offered in
   the D-H PN Hello Response message.  If the NEA Server's policy does
   not allow the use of any of the D-H groups offered by the NEA Client,
   this MUST result in the unsuccessful termination of the D-H PN.  The
   NEA Server MAY decide to continue with an EAP-TNC exchange without
   the D-H PN protections by sending a message with the S or D flags set
   to zero and an empty data field.  If the NEA Server decides to select
   an offered D-H group, the Posture Transport Server can offer its D-H
   public value (using the size from the selected group) and include a
   nonce for freshness of the exchange in the following D-H PN
   Parameters Request message.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Reserved    |   D-H Group   |   Hash Alg.   | Nonce Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    NEA Server Nonce (S-Nonce) ...             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       D-H Public Value (S-Pub)  ...           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Reserved

      This field MUST be set to zero and MUST be ignored by compliant
      implementations.

   D-H Group

      Selected D-H Group (single flag) from set offered by the Posture
      Transport Client in the D-H PN Hello Response message.  See
      section 3.5.5. for description of the D-H groups and their
      representation in this field.

   Hash Alg(orithm)


Hanna                    Expires July 4, 2010                 [Page 13]

Internet-Draft                  PT-EAP                     January 2010


      Flag field indicating the set of supported hash algorithms for the
      NEA Server.  See section 3.5.4. for a description of the defined
      hash algorithms and their representation in this field.

   Nonce Length

      Length of the nonce field in bytes.  This value MUST be greater
      than 16 and MUST be greater then or equal to the Min Nonce Len
      specified by the NEA Client's D-H PN Hello Response message.

   NEA Server Nonce (S-Nonce)

      High entropy random data used to assure the freshness of the
      session.  Nonces MUST NOT be repeated or be predictable by other
      parties.

   D-H Public Value

      NEA Server's public value for this D-H exchange.  The size of this
      field is determined by the Posture Transport Server selected D-H
      group to use.  See section 3.5.5. for the lengths used for each D-
      H group.

3.5.2.4. D-H PN Parameters Response Format

   This section describes the data field of the NEA Client's parameter
   response message that completes the D-H PN exchange.  This message
   establishes the particular hash algorithm for the derivation.
   Because the D-H group has been established, the Posture Transport
   Client can offer its D-H public value and include a nonce for
   freshness of the exchange.  When the Posture Transport Server
   receives this message, both parties will have everything they need to
   perform the remaining transforms to derive the shared secrets.

                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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Nonce Length  |   Hash Alg.   |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      D-H Public Value (C-Pub)  ...            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   NEA Client Nonce (C-Nonce) ...              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Nonce Length



Hanna                    Expires July 4, 2010                 [Page 14]

Internet-Draft                  PT-EAP                     January 2010


      Length of the nonce field in bytes.  This value MUST be greater
      than 16 and SHOULD match the length used by the NEA Server's
      nonce.

   Hash Alg(orithm)

      Selected hash algorithm (single flag) from offered set for use
      later in D-H PN.  See section 3.5.4. for a description of the
      defined hash algorithms.

   Reserved

      This field MUST be set to zero and MUST be ignored by compliant
      implementations.

   D-H Public Value (C-Pub)

      NEA Client's public value for this D-H exchange.  The size of this
      field is indicated by the selected D-H group.

   NEA Client Nonce (C-Nonce)

      High entropy random data used to assure the freshness of the
      session (nonces MUST NOT be repeated or be predictable.)

3.5.3. Diffie-Hellman Pre-Negotiation Protocol

   This section describes the message exchange protocol which occurs
   during the D-H PN.  At any point during the exchange if a party is
   unwilling to accept the options offered by the other party, it SHOULD
   set the D flag to zero indicating it no longer wishes to continue the
   D-H PN.  This MAY result in a fallback to a standard request/response
   protocol if acceptable by both parties.  All D-H PN protocol messages
   MUST have the D flag set to one.

   The following sequence explains the details of the processing of each
   D-H PN message carried by EAP and some background on how it provides
   security against MiTM attacks:

        1. Initially, the NEA Server sends an EAP-Request with the S
          (Start) flag set to one to indicate the beginning of the
          session.  The NEA Server SHOULD check policy to determine if
          the NEA Client should be asked to use the D-H PN and if so
          set the D (D-H PN) flag.  If the D-H PN flag is set, the
          message MUST NOT contain data in the data section and is
          known as a D-H PN Hello Request message.



Hanna                    Expires July 4, 2010                 [Page 15]

Internet-Draft                  PT-EAP                     January 2010


        2. The NEA Client receives the D-H PN Hello Request message.  If
          the NEA Client only supports version 1.0 of IF-T Protocol
          Binding for Tunneled EAP Methods and therefore does not
          recognize the D flag, it would ignore the D flag and try to
          process the data section as a PB-TNC request message so it
          MUST find no data field for backward compatibility.  The NEA
          Client supports the D flag so it will perform the following:

          a. If the D flag is zero, the NEA Client MUST NOT respond with
             a message with the D flag set to one. Instead, it MAY
             terminate the exchange if it requires a D-H PN but will
             usually proceed with EAP-TNC without D-H PN.

          b. If the D flag is one, the NEA Client MAY consult policy to
             decide whether to respond with the D-H PN Hello Response
             message indicating a willingness to perform a D-H PN.  If
             willing to use D-H PN, the NEA Client includes a set of
             acceptable D-H groups and any minimum nonce lengths it
             requires. The NEA Client MAY decline to perform D-H PN by
             sending an EAP-TNC message with the D flag set to zero.  In
             this case, the NEA Server MAY proceed with a NEA exchange
             unprotected by D-H PN or terminate the entire NEA exchange.

        3. If the NEA Server receives the D-H PN Hello Response message,
          this indicates an ability and willingness to perform a D-H PN
          by the NEA Client.  The NEA Server sends a D-H PN Parameters
          Request message selecting a D-H group from those offered by
          the NEA Client.  This message also indicates its set of
          supported hash algorithms, and the NEA Server's public value
          and freshness nonce.

        4. The NEA Client responds with a D-H PN Parameters Response
          Message.  This message MUST select a hash algorithm from the
          offered set.  If no acceptable options were offered the NEA
          Client SHOULD respond with a message with the D flag set to
          zero and proceed with an EAP-TNC response (to the Start
          message) without D-H PN protection.  The NEA Client also
          sends its D-H public value corresponding to the selected D-H
          group and a freshness nonce.

        5. The NEA Server receives the D-H PN Parameters Response
          message and assures the response is consistent with its
          request message and meets its policy.

   At this point the NEA Client and NEA Server compute the shared secret
   key using the Diffie-Hellman algorithm.  Passive MiTM listeners can
   not determine the key value, although an active MiTM that


Hanna                    Expires July 4, 2010                 [Page 16]

Internet-Draft                  PT-EAP                     January 2010


   participates in the D-H PN exchange and acts as a proxy between the
   true NEA Client and NEA Server could share keys with each party.  In
   the proxy case, the true NEA Client and NEA Server do not share a
   common secret key (they each only share a secret with the MiTM
   proxy.)  To detect this style of attack, the NEA Client uses a
   byproduct (Unique-Value-1) of the secret key and both nonces later in
   a computation of a quiz answer sent in an PA-TNC attribute request
   during the assessment.  Because the true NEA Client and NEA Server
   know different D-H values, the true NEA Client computes a different
   quiz result than what is expected by the NEA Server so the assessment
   fails.

   Both parties compute the following:

        6.Compute Unique-Value-1 = HASH ("1" | C-Nonce | S-Nonce | D-H
          Shared Secret Key)  The NEA Client saves Unique-Value-1 for
          later use with the PA-TNC quiz requests.  If the value length
          is >20 bytes (e.g. when the selected HASH is SHA-256), the
          value MUST be truncated to the 20 most significant bytes.
          Later when the NEA Client is asked to produce a quiz result
          during the PA-TNC assessment, this value is used in the
          computation (e.g. hashed with other posture information).
          The NEA Server can also compute Unique-Value-1 and the quiz
          result so can recognize a correct response.  Note that
          Unique-Value-1 isn't the actual secret key used to protect
          traffic.

        7. Next, the NEA Client and NEA Server compute the following
          value that will be used later by EAP-TNC:

            Unique-Value-2 = HASH ("2" | C-Nonce | S-Nonce | D-H Shared
            Secret Key)

        8. After the completion of the D-H PN protocol, both entities
          MUST set the D flag to zero and then use the data field to
          exchange PB-TNC batches.  The NEA Server will start by
          sending an EAP-TNC message with no Data and the D and S flags
          set to zero. The NEA Client will respond with an EAP-TNC
          message containing its first PB-TNC batch.

        9. When a D-H PN has successfully completed, the NEA Client and
          NEA Server MUST compute a running hash (using the selected
          algorithm) including the complete contents (from the Code
          field through the Data field, inclusive) of each EAP-TNC
          message sent/received in sequence during the assessment.
          This running hash is performed by repeated use of the
          following after receiving or sending an EAP-TNC Message:


Hanna                    Expires July 4, 2010                 [Page 17]

Internet-Draft                  PT-EAP                     January 2010


            Unique-Value-2 = HASH (Unique-Value-2 | HASH (EAP-TNC
            Message))

        10. The result (final Unique-Value-2) is a value that is
          cryptographically computed from the D-H PN secret key, nonce
          pair and the contents of all of the messages exchanged (thus
          all the posture information responses.)

        11. At the completion of the EAP-TNC exchanges when the D-H PN
          has been used, the final Unique-Value-2 MUST be exported and
          mixed into the EAP tunnel method's session keys.  An
          additional EAP tunnel method round trip is required to assure
          that NEA Client and NEA Server both computed the same value.
          If this occurred, then both parties knew the secret D-H PN
          key, nonce pair and observed the same set of EAP-TNC message
          (thus allowing for detection of MiTM message tampering.)  If
          both do not compute the same final Unique-Value-2, then the
          final EAP tunnel method message exchange (cryptographic
          binding check) will not properly decrypt, so the session MUST
          be considered compromised.

        12. Finally after the outer EAP tunnel method completes, it's
          critical that the subsequent communications continue to be
          protected from active attacks by a MiTM.  This SHOULD be
          achieved by leveraging keys derived from the Unique-Value-2
          known by both parties to encrypt and integrity protect future
          traffic.  Wireless 802.1X has provisions for provisioning a
          key for this purpose, but wired 802.1X requires an equivalent
          mechanism (possibly part of 802.1AE.)

3.5.4. Diffie-Hellman Pre-Negotiation Hash Algorithm Values

   This section defines the values for the Hash Alg(orithm) field for
   the various hashing algorithms supported by D-H PN.  The values are
   as follows:

   +-+-+-+-+-+-+-+-+
   |R R R R R R 2 1|
   +-+-+-+-+-+-+-+-+

                  1 - SHA-1 [5]

                  2 - SHA-256 [5]

                  R - Reserved for future use




Hanna                    Expires July 4, 2010                 [Page 18]

Internet-Draft                  PT-EAP                     January 2010


   Implementations compliant with this specification MUST ignore flags
   set that they are unable to support.  Compliant implementations MUST
   NOT set hash algorithm values that they are unable to support.

3.5.5. Diffie-Hellman Group Values

   This section defines the flag values for the D-H Group field used in
   several D-H PN messages.  The values are as follows:

   +-+-+-+-+-+-+-+-+
   |R R R R R 3 2 1|
   +-+-+-+-+-+-+-+-+

      1 - Use of values from group 2 from IKE.

      2 - Use of values from group 5 from IKE.

      3 - Use of values from group 14 from IKE.

      R - Reserved for future use

   Implementations compliant with this specification MUST ignore flags
   set that they are unable to support.  Compliant implementations MUST
   NOT set D-H Group values that they are unable to support.

3.5.5.1. Diffie-Hellman Group 1 Definitions

   This section defines the Diffie-Hellman algorithm values that MUST be
   used when using group 1 (flag 1 above) of the D-H PN.  This group is
   taken from group 2 of IKE.

   The public values exchanged when using this group MUST be 128 bytes
   in length.

   The Diffie-Hellman generator (g) MUST be 2.

   The prime modulus is the 128 byte value:

      2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }

   which has a hexadecimal value of:

      FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
      8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
      302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
      A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
      49286651 ECE65381 FFFFFFFF FFFFFFFF


Hanna                    Expires July 4, 2010                 [Page 19]

Internet-Draft                  PT-EAP                     January 2010




3.5.5.2. Diffie-Hellman Group 2 Definitions

   This section defines the Diffie-Hellman algorithm values that MUST be
   used when using group 2 (flag 2 above) of the D-H PN.  This group is
   based on group 5 from IKE MODP Groups [6].

   The public values exchanged when using this group MUST be 192 bytes
   in length.

   The Diffie-Hellman generator (g) MUST be 2.

   The prime modulus is the 192 byte value:

                  2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }

   which has a hexadecimal value of:

                  FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
                  29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
                  EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
                  E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
                  EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
                  C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
                  83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
                  670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF

3.5.5.3. Diffie-Hellman Group 3 Definitions

   This section defines the Diffie-Hellman algorithm values that MUST be
   used when using group 3 (flag 3 above) of the D-H PN. This group is
   based on group 14 from IKE MODP Groups [6].

   The public values exchanged when using this group MUST be 256 bytes
   in length.

   The Diffie-Hellman generator (g) MUST be 2.

   The prime modulus is the 256 byte value:

      2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }

    which has a hexadecimal value of:

                  FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
                  29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD


Hanna                    Expires July 4, 2010                 [Page 20]

Internet-Draft                  PT-EAP                     January 2010


                  EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
                  E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
                  EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
                  C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
                  83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
                  670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
                  E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
                  DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
                  15728E5A 8AACAA68 FFFFFFFF FFFFFFFF

4. Security Considerations

   This section discusses the major threats and countermeasures provided
   by the EAP-TNC inner EAP method. As discussed throughout the
   document, the EAP-TNC method is designed to run inside an EAP tunnel
   method which is capable of protecting the EAP-TNC protocol from many
   threats.
4.1.  Trust Relationships

   In order to understand where security countermeasures are necessary,
   this section starts with a discussion of where the NEA architecture
   envisions some trust relationships between the processing elements of
   the PT-EAP protocol.  The following sub-sections discuss the trust
   properties associated with each portion of the NEA reference model
   directly involved with the processing of the PT-TNC protocol.

4.1.1. Posture Transport Client

   The Posture Transport Client is trusted by the Posture Broker Client
   to:

   o  Not to observe, fabricate or alter the contents of the PB-TNC
      batches received from the network

   o  Not to observe, fabricate or alter the PB-TNC batches passed down
      from the Posture Broker Client for transmission on the network

   o  Transmit on the network any PB-TNC batches passed down from the
      Posture Broker Client

   o  Deliver properly security protected messages received from the
      network that are destined for the Posture Broker Client

   o  Provide configured security protections (e.g. authentication,
      integrity and confidentiality) for the Posture Broker Client's PB-
      TNC batches sent on the network


Hanna                    Expires July 4, 2010                 [Page 21]

Internet-Draft                  PT-EAP                     January 2010


   o  Expose the authenticated identity of the Posture Transport Server

   o  Verify the security protections placed upon messages received from
      the network to ensure the messages are authentic and protected
      from attacks on the network

   o  Provide a secure, reliable, in order delivery, full duplex
      transport for the Posture Broker Client's messages

   The Posture Transport Client is trusted by the Posture Transport
   Server to:

   o  Not send malicious traffic intending to harm (e.g. denial of
      service) the Posture Transport Server

   o  Not to intentionally send malformed messages to cause processing
      problems for the Posture Transport Server

   o  Not to send invalid or incorrect responses to messages (e.g.
      errors when no error is warranted)

   o  Not to ignore or drop messages causing issues for the protocol
      processing

   o  Verify the security protections placed upon messages received from
      the network to ensure the messages are authentic and protected
      from attacks on the network

4.1.2. Posture Transport Server

   The Posture Transport Server is trusted by the Posture Broker Server
   to:

   o  Not to observe, fabricate or alter the contents of the PB-TNC
      batches received from the network

   o  Not to observe, fabricate or alter the PB-TNC batches passed down
      from the Posture Broker Server for transmission on the network

   o  Transmit on the network any PB-TNC batches passed down from the
      Posture Broker Server

   o  Deliver properly security protected messages received from the
      network that are destined for the Posture Broker Server





Hanna                    Expires July 4, 2010                 [Page 22]

Internet-Draft                  PT-EAP                     January 2010


   o  Provide configured security protections (e.g. authentication,
      integrity and confidentiality) for the Posture Broker Server's
      messages sent on the network

   o  Expose the authenticated identity of the Posture Transport Client

   o  Verify the security protections placed upon messages received from
      the network to ensure the messages are authentic and protected
      from attacks on the network

   The Posture Transport Server is trusted by the Posture Transport
   Client to:

   o  Not send malicious traffic intending to harm (e.g. denial of
      service) the Posture Transport Server

   o  Not to send malformed messages

   o  Not to send invalid or incorrect responses to messages (e.g.
      errors when no error is warranted)

   o  Not to ignore or drop messages causing issues for the protocol
      processing

   o  Verify the security protections placed upon messages received from
      the network to ensure the messages are authentic and protected
      from attacks on the network

4.2. Security Threats and Countermeasures

   Beyond the trusted relationships assumed in section 4.1. the PT-EAP
   EAP method faces a number of potential security attacks that could
   require security countermeasures.

   Generally, the PT protocol is responsible for providing strong
   security protections for all of the NEA protocols so any threats to
   PT's ability to protect NEA protocol messages could be very damaging
   to deployments.  For the PT-EAP method, most of the cryptographic
   security in provided by the outer EAP tunnel method and EAP-TNC is
   encapsulated within the protected tunnel.   Therefore, this section
   highlights the cryptographic requirements that need to be met by the
   EAP tunnel method carrying EAP-TNC in order to meet the NEA PT
   requirements.

   Once the message is delivered to the Posture Broker Client or Posture
   Broker Server, the posture brokers are trusted to properly safely
   process the messages.


Hanna                    Expires July 4, 2010                 [Page 23]

Internet-Draft                  PT-EAP                     January 2010


4.2.1. Message Theft

   When EAP-TNC messages are sent over unprotected network links or
   spanning local software stacks that are not trusted, the contents of
   the messages may be subject to information theft by an intermediary
   party.  This theft could result in information being recorded for
   future use or analysis by the adversary.  Messages observed by
   eavesdroppers could contain information that exposes potential
   weaknesses in the security of the endpoint, or system fingerprinting
   information easing the ability of the attacker to employ attacks more
   likely to be successful against the endpoint.  The eavesdropper might
   also learn information about the endpoint or network policies that
   either singularly or collectively is considered sensitive
   information.  For example, if EAP-TNC is housed in an EAP tunnel
   method that does not provide confidentiality protection, an adversary
   could observe the PA-TNC attributes included in the PB-TNC batch and
   determine that the endpoint is lacking patches, or particular sub-
   networks have more lenient policies.

   In order to protect again NEA assessment message theft, the EAP
   tunnel method carrying EAP-TNC MUST provide strong cryptographic
   authentication, integrity and confidentiality protection.  The use of
   bi-directional authentication in the EAP tunnel method carrying EAP-
   TNC ensures that only properly authenticated and authorized parties
   may be involved in an assessment message exchange.  When EAP-TNC is
   carried with a cryptographically protected EAP tunnel method like
   EAP-TTLS, all of the PB-TNC and PA-TNC protocol messages contents are
   hidden from potential theft by intermediaries lurking on the network.

4.2.2. Message Fabrication

   Attackers on the network or present within the NEA system could
   introduce fabricated PT-EAP messages intending to trick or create a
   denial of service against aspects of an assessment.  For example, an
   adversary could attempt to insert into the message exchange fake PT-
   EAP error codes in order to disrupt communications.

   The EAP tunnel method carrying an EAP-TNC method needs to provide
   strong security protections for the complete message exchange over
   the network.  These security protections prevent an intermediary from
   being able to insert fake messages into the assessment.  For example,
   the EAP-TTLS method's use of hashing algorithms provides strong
   integrity protections that allow for detection of any changes in the
   content of the message exchange.  Additionally, adversaries are
   unable to observe the EAP-TNC method housed inside of an encrypting
   EAP tunnel method (e.g. EAP-TTLS) because the messages are encrypted
   by the TLS [2] ciphers, so an attacker would have difficulty in


Hanna                    Expires July 4, 2010                 [Page 24]

Internet-Draft                  PT-EAP                     January 2010


   determining where to insert the falsified message, since the attacker
   is unable to determine where the message boundaries exist.

4.2.3. Message Modification

   This attack could allow an active attacker capable of intercepting a
   message to modify a PT-EAP message or transported PA-TNC attribute to
   a desired value to ease the compromise of an endpoint.  Without the
   ability for message recipients to detect whether a received message
   contains the same content as what was originally sent, active
   attackers can stealthily modify the attribute exchange.

   The EAP-TNC method leverages the EAP tunnel method (e.g. EAP-TTLS) to
   provide strong authentication and integrity protections as a
   countermeasure to this threat.  The bi-directional authentication
   prevents the attacker from acting as an active man-in-the-middle to
   the protocol that could be used to modify the message exchange.  The
   strong integrity protections (hashing) offered by EAP-TTLS allows the
   EAP-TNC message recipients to detect message alterations by other
   types of network based adversaries.  Because EAP-TNC does not itself
   provide explicit integrity protection for the EAP-TNC payload, an EAP
   tunnel method that offers strong integrity protection is required to
   mitigate this threat.

4.2.4. Denial of Service

   A variety of types of denial of service attacks are possible against
   the PT-EAP if the message exchange are left unprotected while
   traveling over the network.   The Posture Transport Client and
   Posture Transport Server are trusted not to participate in the denial
   of service of the assessment session, leaving the threats to come
   from the network.

   The EAP-TNC method primarily relies on the outer EAP tunnel method to
   provide strong authentication (at least of one party) and deployers
   are expected to leverage other EAP methods to authenticate the other
   party (typically the client) within the protected tunnel.  The use of
   a protected bi-directional authentication will prevent unauthorized
   parties from participating in a PT-EAP exchange.

   After the cryptographic authentication by the EAP tunnel method, the
   session can be encrypted and hashed to prevent undetected
   modification that could create a denial of service situation.
   However it is possible for an adversary to alter the message flows
   causing each message to be rejected by the recipient because it fails
   the integrity checking.



Hanna                    Expires July 4, 2010                 [Page 25]

Internet-Draft                  PT-EAP                     January 2010


4.2.5. Nested Tunnel Attacks

   The PT-EAP protocol works on the premise that the EAP tunnel method
   is capable of carrying (and protecting) various inner methods that
   perform additional security exchanges to establish the authenticity
   and integrity of the endpoint.  While this model is very flexible
   since it allows for the variety of existing EAP methods to be
   leveraged within the tunnel, it may introduce vulnerabilities.  One
   such vulnerability is an attack described in "Man-in-the-Middle
   Attack against Tunneled Authentication Protocols" described in the
   2003 Security Protocols Workshop paper by Asokan, Niemi, and Nyberg
   [13].  This document will refer to the attack discussed by Asokan and
   others as the "nested tunnel attack" for brevity.

   The nested tunnel attack takes advantage of the fact that there is no
   strong linkage between the outer EAP tunnel method and the inner EAP
   method so a MiTM could be forwarding traffic learned from an earlier
   unprotected observed authentication (or assessment) or actively
   proxying an ongoing unprotected assessment.

   For example, if a normally compliant and authorized enterprise laptop
   (referred to as "laptop1") became infected with malware and wished to
   access the enterprise network despite now being non-compliant the
   following might occur:

        1. Attacker sets up laptop2 with same software as on compliant
          laptop1 (minus malware) and configures to provide posture to
          laptop1 using NEA protocols.

        2. When legitimate user attempts to join enterprise network with
          laptop1, malware delays join and notifies the attacker who
          triggers laptop2 to attempt to join network by sending
          authentication and posture information to laptop1 (even
          securely in an EAP tunnel).

        3. Now armed with a NEA session to laptop2, laptop1 attempts to
          join enterprise network with secure tunneled PT-EAP exchange
          to enterprise's NEA Server

        4. After EAP tunnel method establishes tunnel, NEA Server uses
          EAP-TNC method to request laptop1 provide posture to join
          network

        5. Laptop1 relays posture requests over other EAP tunnel to
          laptop2 (using EAP-TNC) who responds with compliant posture
          information.



Hanna                    Expires July 4, 2010                 [Page 26]

Internet-Draft                  PT-EAP                     January 2010


        6. Laptop1 relays the laptop2 responses to the enterprise NEA
          Server

        7. Steps 4-6 repeat as necessary

        8. Enterprise NEA Server believes laptop1 is compliant with
          policy despite it containing significant malware

   This attack exploits the fact that the inner and outer EAP methods
   are independent from each other since laptop1 is able to obtain
   compliant posture information from laptop2 over a different tunnel
   and re-use it.  In order to bind the inner and out methods together,
   this specification includes a Diffie-Hellman Pre-Negotiation (D-H PN)
   which creates a per-assessment freshness value.

   When the D-H PN value is combined with a hash of the assessment
   messages and the resulting value is exported and mixed into the outer
   EAP tunnel method's keys, both parties can perform a simple roundtrip
   confirmation message to ensure both know the D-H PN secret, the hash
   of the assessment and the original outer tunnel methods encryption
   key.  This cryptographically binds the one (or more) inner EAP
   methods exporting keys with the outer tunnel method and provides more
   freshness to the assessment session.  For details of D-H PN, see
   section 3.5.

   In addition, a special pair of PA-TNC attributes can be exchanged
   after the D-H PN has completed that include a simple proof of
   knowledge quiz that the intermediary is not able to easily solve with
   information seen on the network.  For example, the NEA Server could
   send a "quiz" question to the NEA Client where the response would
   include a hash(D-H PN Secret, "quiz_answer").  The intermediary won't
   know the D-H PN Secret if it wasn't involved in the D-H PN.  If it
   was involved, it shouldn't be able to figure out the quiz answer
   which involves a question about what a clean system should look like.

   The countermeasure provide mitigation because if an active MiTM
   (laptop1) takes part in the D-H PN it establishes shared values with
   the enterprise NEA Server that aren't actually known by laptop2, so
   can't be included in laptop2's exported keys or in the quiz answer.

   If a MiTM (laptop1) just forwarded the D-H PN protocol over a tunnel
   to laptop2 so that clean laptop2 and the enterprise NEA Server were
   selecting the D-H values and nonces, laptop1 would be unable to
   determine the established secret since it lacks knowledge of any D-H
   private values and would be unable to complete the outer EAP tunnel
   exchange once the secret was mixed into the session keys.



Hanna                    Expires July 4, 2010                 [Page 27]

Internet-Draft                  PT-EAP                     January 2010


   In order for the MiTM protection to continue during the subsequent
   communications on the network, the communications SHOULD protect the
   data exchanges using keys based on the final EAP tunnel method keys
   that were mixed with the D-H secret keys.  At present, 802.1X for
   wireless use has provisions for such a key to be used.  However wired
   802.1X lacks the use of keys to protect the communications.  These
   unprotected flows are again vulnerable to a variety of attacks
   including alteration or replay by a MiTM.  It is believed that the
   use of 802.1AE will address this issue so deployers should consider
   this if their threat model (especially with respect to wired 802.1X)
   warrants ongoing protections.

   Note that this process does not prevent the malware on laptop1 from
   lying about its posture; this approach merely addresses the network
   based MiTM attack.  Detection of local malware lying about its
   posture is outside the scope of NEA but is being researched and
   standardized in the Trusted Computing Group.

4.3. Requirements for EAP Tunnel Methods

   Because the PT-EAP inner method described in this specification
   relies on the outer EAP tunnel method for a majority of its security
   protections, this section reiterates the PT requirements that MUST be
   met by the IETF standard EAP tunnel method for use with PT-EAP.

   The security requirements described in this specification MUST be
   implemented in any product claiming to be PT-EAP compliant.  The
   decision of whether a particular deployment chooses to use these
   protections is a deployment issue.  A customer may choose to avoid
   potential deployment issues or performance penalties associated with
   the use of cryptography when the required protection has been
   achieved through other mechanisms (e.g. physical isolation).  If
   security mechanisms may be deactivated by policy, an implementation
   should offer an interface to query how a message will be (or was)
   protected by PT so higher layer NEA protocols can factor this into
   their decisions.

   RFC 5209 includes the following requirement that is to be applied
   during the selection of the EAP tunnel method(s) used in conjunction
   with EAP-TNC:

      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.




Hanna                    Expires July 4, 2010                 [Page 28]

Internet-Draft                  PT-EAP                     January 2010


   Note that mutual authentication could be achieved by a combination of
   a strong authentication of one party (e.g. TLS server when EAP-TTLS
   is used) by the EAP tunnel method in conjunction with a second
   authentication of the other party (e.g. client authentication inside
   the protected tunnel) by another EAP method running prior to EAP-TNC.

   Having the Posture Transport Client always authenticate the Posture
   Transport Server provides assurance to the NEA Client that the NEA
   Server is authentic (not a rogue or MiTM) prior to disclosing secret
   or potentially privacy sensitive information about what is running or
   configured on the endpoint.  However the NEA Server's policy may
   allow for the delay of the authentication of the NEA Client until a
   suitable protected channel has been established allowing for non-
   cryptographic NEA Client credentials (e.g. username/password) to be
   used.  Whether the communication channel is established with both or
   one party performing a cryptographic authentication, the resulting
   channel needs to provide strong integrity and confidentiality
   protection to its contents.  These protections are to be bound to at
   least the authentication of the NEA Client, so the session is
   cryptographically bound to a particular authentication event.

4.4. Candidate EAP Tunnel Method Protections

   This section discusses how EAP-TNC is used within various EAP tunnel
   methods meet the PT requirements from section 4.3.

   EAP-FAST and EAP-TTLS make use of TLS [2] to protect the transport of
   information between the NEA Client and NEA Server.  Each of these EAP
   tunnel methods has two phases. In the first phase, a TLS tunnel is
   established between NEA Client and NEA Server. In the second phase,
   the tunnel is used to pass other information.  PT-EAP requires that
   establishing this tunnel include at least an authentication of the
   NEA Server by the NEA Client.

   The phase two dialog may include authentication of the user by doing
   other EAP methods or in the case of TTLS by using non-EAP
   authentication dialogs.  EAP-TNC is also carried by the phase two
   tunnel allowing the NEA assessment to be within an encrypted and
   integrity protected transport.

   With all these methods, a cryptographic key is derived from the
   authentication that may be used to secure later transmissions.  Each
   of these methods employs at least a NEA Server authentication using
   an X.509 certificates.  Within each EAP tunnel method will exist a
   set of inner EAP method (or an equivalent using TLVs if inner methods
   aren't directly supported.)  These inner methods may perform
   additional security handshakes including more granular


Hanna                    Expires July 4, 2010                 [Page 29]

Internet-Draft                  PT-EAP                     January 2010


   authentications or exchanges of integrity information (such as EAP-
   TNC.)  At some point after the conclusion of each inner EAP method,
   some of the methods will export the established secret keys to the
   outer tunnel method.  It's expected that the outer method will
   cryptographically mix these keys into any keys it is currently using
   to protect the session and perform a final operation to determine
   whether both parties have arrived at the same mixed key.  This
   cryptographic binding of the inner method results to the outer
   methods keys is essential for detection of nested method attacks, see
   section 4.2.5.

4.5. Security Claims for EAP-TNC as per RFC3748

   This section summarizes the security claims as required by RFC3748
   Section 7.2:

      Auth. mechanism:              None
      Ciphersuite negotiation:      No
      Mutual authentication:        No
      Integrity protection:         No
      Replay protection:            No
      Confidentiality:              No
      Key derivation:               Yes
      Key strength:                 Depends on D-H Group and Hash used
      Dictionary attack resistant:  N/A
      Fast reconnect:               No
      Crypt. binding:               N/A
      Session independence:         N/A
      Fragmentation:                Yes
      Channel binding:              No

5. Privacy Considerations

   The role of PT-EAP is to act as a secure transport for PB-TNC over a
   network before the endpoint has been admitted to the network.  As a
   transport protocol, PT-EAP does not directly utilize or require
   direct knowledge of any personally identifiable information (PII).
   PT-EAP will typically be used in conjunction with other EAP methods
   that provide for the user authentication (if bi-directional
   authentication is used), so the user's credentials are not directly
   seen by the EAP-TNC inner method.  Therefore, the Posture Transport
   Client and Posture Transport Server's implementation of EAP-TNC MUST
   NOT observe the contents of the carried PB-TNC batches that could
   contain PII carried by PA-TNC or PB-TNC.

   While EAP-TNC does not provide cryptographic protection for the PB-
   TNC batches, it is designed to operate within an EAP tunnel method


Hanna                    Expires July 4, 2010                 [Page 30]

Internet-Draft                  PT-EAP                     January 2010


   that provides strong authentication, integrity and confidentiality
   services.  Therefore, it is important for deployers to leverage these
   protections in order to prevent disclosure of PII potentially
   contained within PA-TNC or PB-TNC within the EAP-TNC payload.

6. IANA Considerations

   This document defines an EAP method type named EAP-TNC with the
   value 38.

   [IANA Note: This value was previously reserved for another
   purpose but has been used for EAP-TNC for some time and never
   used for another purpose so please assign this value to EAP-
   TNC.]

   This document also defines three new IANA registries: EAP-TNC
   Versions, PT-EAP D-H PN Hash Algorithm IDs, and PT-EAP D-H PN
   Group IDs.  This section explains how these registries work.

   Because only eight (8) values are available in each of these
   registries, a high bar is set for new assignments. The only way
   to register new values in these registries is through Standards
   Action (via an approved Standards Track RFC).

6.1. Registry for EAP-TNC Versions

   The name for this registry is "EAP-TNC Versions".  Each entry
   in this registry should include a decimal integer value between
   1 and 7 identifying the version, and a reference to the RFC
   where the version is defined.

   The following entries for this registry are defined in this
   document.  Once this document becomes an RFC, they should
   become the initial entries in the registry for EAP-TNC
   Versions.  Additional entries to this registry are added by
   Standards Action, as defined in RFC 5226 [8].

      Value                 Defining Specification
      -----                 ----------------------
          1                 RFC # Assigned to this I-D


6.2. Registry for PT-EAP D-H PN Hash Algorithm IDs

   The name for this registry is "PT-EAP D-H PN Hash Algorithm
   IDs".  Each entry in this registry should include a human-
   readable name, a decimal integer value between 1 and 8


Hanna                    Expires July 4, 2010                 [Page 31]

Internet-Draft                  PT-EAP                     January 2010


   representing its location in the bit map, and a reference to
   the RFC where the contents of this message type are defined.

   The following entries for this registry are defined in this
   document.  Once this document becomes an RFC, they should
   become the initial entries in the registry for PT-EAP D-H PN
   Hash Algorithm IDs.  Additional entries to this registry are
   added by Standards Action, as defined in RFC 5226 [8].

      Bit Position      Name                 Defining Specification
      ------------      ----                 ----------------------
          1             SHA-1             RFC # Assigned to this I-D
          2             SHA-256           RFC # Assigned to this I-D


6.3. Registry for PT-EAP D-H PN Group IDs

   The name for this registry is "PT-EAP D-H PN Group IDs".  Each
   entry in this registry should include a human-readable name, a
   decimal integer value between 1 and 8 representing its location
   in the bit map, and a reference to the specification where the
   contents of this message type are defined.

   The following entries for this registry are defined in this
   document.  Once this document becomes an RFC, they should
   become the initial entries in the registry for PT-EAP D-H PN
   Group IDs.  Additional entries to this registry are added by
   Standards Action, as defined in RFC 5226.

      Bit Position      Name                 Defining Specification
      ------------      ----                 ----------------------
          1             Group 2 (IKE)     RFC # Assigned to this I-D
          2             Group 5 (IKE)     RFC # Assigned to this I-D
          3             Group 14 (IKE)    RFC # Assigned to this I-D


7. References

7.1. Normative References

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

   [2]   Dierks T., Rescorla E., "The Transport Layer Security (TLS)
         Protocol Version 1.2", RFC 5246, August 2008.




Hanna                    Expires July 4, 2010                 [Page 32]

Internet-Draft                  PT-EAP                     January 2010


   [3]   Sangster P., Narayan K., "PA-TNC: A Posture Attribute Protocol
         (PA) Compatible with TNC", RFC XXXX, January 2010.

   [4]   Sahita, R., Hanna, S., and R. Hurst, "PB-TNC: A Posture Broker
         Protocol (PB) Compatible with TNC", RFC YYYY, January 2010.

   [5]   NIST, "Secure Hash Standard", FIPS 180-1, National Institute of
         Standards and Technology, U.S. Department of Commerce, May
         1994, http://csrc.nist.gov/CryptoToolkit/shs/dfips-180-2.pdf

   [6]   T. Kivinen, M. Kojo, "More Modular Exponential (MODP) Diffie-
         Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May
         2003.

   [7]   LAN/MAN Standards Committee of the IEEE Computer Society,
         Standard for Local and Metropolitan Area Networks - Port Based
         Network Access Control, IEEE Std. 802.1X-2004, December 2004.

   [8]   T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", RFC 5226, May 2008.

7.2. Informative References

   [9]   Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
         Tardo, "Network Endpoint Assessment (NEA): Overview and
         Requirements", RFC 5209, June 2008.

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

   [11]  Sangster, P., "PT-TLS: A Posture Transport Protocol (PT)
         Compatible with TNC Using Transport Layer Security (TLS)",
         draft-sangster-nea-pt-tnc-00.txt, work in progress, January
         2010.

   [12]  Trusted Computing Group, "TNC IF-T: Binding to TLS",
         http://www.trustedcomputinggroup.org/files/resource_files/51F07
         57E-1D09-3519-AD63B6FD099658A6/TNC_IFT_TLS_v1_0_r16.pdf, May
         2009.

   [13]  N. Asokan, Valtteri Niemi, Kaisa Nyberg, "Man in the Middle
         Attacks in Tunneled Authentication Protocols", Nokia Research
         Center, Finland, Nov. 11, 2002,
         http://eprint.iacr.org/2002/163.pdf




Hanna                    Expires July 4, 2010                 [Page 33]

Internet-Draft                  PT-EAP                     January 2010


   [14]  N. Cam-Winget, D. McGrew, J. Salowey, H. Zhou, "The Flexible
         Authentication via Secure Tunneling Extensible Authentication
         Protocol Method (EAP-FAST)", RFC 4851, May 2007.

   [15]  C. Kaufman, "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
         December 2005.

   [16]  P. Funk, S. Blake-Wilson, "Extensible Authentication Protocol
         Tunneled Transport Layer Security Authenticated Protocol
         Version 0 (EAP-TTLSv0)", RFC 5281, August 2008.

   [17]  K. Hoeper, S. Hanna, H. Zhou, J. Salowey, "Requirements for a
         Tunnel Based EAP Method", draft-ietf-emu-eaptunnel-req-04.txt
         (work in progress), October 2009.

   [18]  D. Simon, B. Aboba, R. Hurst, "The EAP-TLS Authentication
         Protocol", RFC 5216, March 2008.

8. Acknowledgments

   Thanks to the Trusted Computing Group for contributing the initial
   text upon which this document was based.

   The authors of this draft would like to acknowledge the following
   people who have contributed to or provided substantial input on the
   preparation of this document or predecessors to it: Amit Agarwal,
   Morteza Ansari, Diana Arroyo, Stuart Bailey, Boris Balacheff, Uri
   Blumenthal, Gene Chang, Scott Cochrane, Pasi Eronen, Aman Garg,
   Sandilya Garimella, David Grawrock, Thomas Hardjono, Chris Hessing,
   Ryan Hurst, Hidenobu Ito, John Jerrim, Meenakshi Kaushik, Greg
   Kazmierczak, Scott Kelly, Bryan Kingsford, PJ Kirner, Sung Lee, Lisa
   Lorenzin, Mahalingam Mani, Bipin Mistry, Seiji Munetoh, Rod
   Murchison, Barbara Nelson, Kazuaki Nimura, Ron Pon, Ivan Pulleyn,
   Alex Romanyuk, Ravi Sahita, Chris Salter, Mauricio Sanchez, Paul
   Sangster, Dean Sheffield, Curtis Simonson, Jeff Six, Ned Smith,
   Michelle Sommerstad, Joseph Tardo, Lee Terrell, Chris Trytten, and
   John Vollbrecht.

   This document was prepared using 2-Word-v2.0.template.dot.










Hanna                    Expires July 4, 2010                 [Page 34]

Internet-Draft                  PT-EAP                     January 2010


Appendix A.                 Evaluation Against NEA Requirements

   This section evaluates the PT-EAP protocol against the PT
   requirements defined in the NEA Overview and Requirements and
   PB-TNC specifications.  Each subsection considers a separate
   requirement and highlights how PT-EAP meets the requirement.

A.1. Evaluation Against Requirement C-1

   Requirement C-1 says:

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

   PT-EAP meets this requirement.  Use of the EAP protocol along
   with EAP-TNC and suitable EAP tunnel methods will allow for
   multiple roundtrips.

A.2. Evaluation Against Requirements C-2

   Requirement C-2 says:

   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-EAP does NOT meet this requirement.  Generally EAP is used
   by the endpoint during the joining of the network.  At that
   time, the endpoint lacks an IP address so is unable to accept
   inbound posture assessment requests from the NEA Server.
   Subsequent reassessments of the endpoint after it has been
   given access to a portion of the IP network can use the PT-TLS
   protocol that supports the NEA Client and NEA Server to
   initiate an assessment.

A.3. Evaluation Against Requirements C-3

   Requirement C-3 says:

   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.

   PT-EAP meets this requirement by leveraging the security
   capabilities of the underlying EAP tunnel method.  EAP-TNC
   itself does not provide protection against a variety of


Hanna                    Expires July 4, 2010                 [Page 35]

Internet-Draft                  PT-EAP                     January 2010


   potential attacks (beside the Diffie-Hellman Pre-Negotiation
   support) so must rely on cryptographic support by the EAP
   tunnel method.

A.4. Evaluation Against Requirements C-4

   Requirement C-4 says:

   C-4   The PA and PB protocols MUST be capable of operating over
   any PT protocol.  For example, the PB protocol must provide a
   transport independent interface allowing the PA protocol to
   operate without change across a variety of network protocol
   environments (e.g. EAP/802.1X, PANA, TLS and IKE/IPsec).

   Not applicable to PT, but the PT-EAP is independent of PA and
   PB allowing those protocols to operate over other PT protocols.

A.5. Evaluation Against Requirements C-5

   Requirement C-5 says:

   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.

   Based on this requirement, PT-EAP should receive a strong
   preference.  PT-EAP is equivalent with IF-T Binding to Tunneled
   EAP Methods 1.1, an open TCG specification that has been widely
   implemented.

A.6. Evaluation Against Requirements C-6

   Requirement C-6 says:

   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-EAP meets this requirement.  The PT-EAP protocol is
   independent of the number of Posture Collectors and Posture
   Validators.





Hanna                    Expires July 4, 2010                 [Page 36]

Internet-Draft                  PT-EAP                     January 2010


A.7. Evaluation Against Requirements C-7

   Requirement C-7 says:

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

   PT-EAP meets this requirement, subject to the limitations of
   the underlying EAP protocol.  PT-EAP allows for the transport
   of a very large number of attributes, up to 2^32 - 1 octets per
   PB-TNC batch.  Furthermore, the PT-EAP protocol transports data
   efficiently, only adding 10 octets of overhead per PT-EAP
   message, which is small considering that a single PT-EAP
   message may carry multiple PA-TNC attributes.

   However, it is important to note that the EAP protocol that
   underlies PT-EAP is not a good choice for transporting large
   amounts of data.  EAP only supports one packet in flight at a
   time, which severely limits throughput.  Further, some network
   equipment imposes timeout restrictions on EAP exchanges.
   Therefore, PT-EAP should not be used to transport large amounts
   of attributes.

A.8. Evaluation Against Requirements C-8

   Requirement C-8 says:

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

   PT-EAP protocols meet this requirement. PT-EAP was designed to
   minimize the amount of overhead included in the protocol to
   allow for efficient use over bandwidth or latency constrained
   network links.

A.9. Evaluation Against Requirements C-9

   Requirement C-9 says:

   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-EAP meets this requirement.  PT-EAP does not include
   messages intended for display to the user.



Hanna                    Expires July 4, 2010                 [Page 37]

Internet-Draft                  PT-EAP                     January 2010


A.10. Evaluation Against Requirements C-10

   Requirement C-10 says:

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

   PA-EAP meets this requirement.  The PT-EAP protocol does not
   include any strings in its fields but it allows higher-layer
   protocols to encode their strings in UTF-8 format.  This allows
   the protocol to support a wide range of languages efficiently.

A.11. Evaluation Against Requirements C-11

   Requirement C-11 says:

   C-11  Due to the potentially different transport
   characteristics provided by the underlying candidate PT
   protocols, the NEA Client and NEA Server MUST be capable of
   becoming aware of and adapting to the limitations of the
   available PT protocol.  For example, some PT protocol
   characteristics that might impact the operation of PA and PB
   include restrictions on: which end can initiate a NEA
   connection, maximum data size in a message or full assessment,
   upper bound on number of roundtrips, and ordering (duplex) of
   messages exchanged.  The selection process for the PT protocols
   MUST consider the limitations the candidate PT protocol would
   impose upon the PA and PB protocols.

   PT-EAP meets this requirement.  The PT-EAP implementations may
   be limited in number of roundtrips, assessment overall time, or
   data transmission.  These constraints will be exposed up the
   protocol stack so the Posture Broker Client and Posture Broker
   Server can optimize and make most efficient use of the
   available resources during the assessment.

A.12. Evaluation Against Requirements PT-1

   Requirement PT-1 says:

   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-EAP meets this requirement.  The PT-EAP encapsulates PB-TNC
   batches without interpreting their contents.



Hanna                    Expires July 4, 2010                 [Page 38]

Internet-Draft                  PT-EAP                     January 2010


A.13. Evaluation Against Requirements PT-2

   Requirement PT-2 says:

   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-EAP meets this requirement.  The PT-EAP leverages an EAP
   tunnel method to provide mutual authentication, integrity
   protection and confidentiality as well as replay protection.
   For more information see the Security Considerations section 4.

A.14. Evaluation Against Requirements PT-3

   Requirement PT-3 says:

   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.

   EAP-TNC includes support for fragmentation and the underlying
   EAP tunnel methods include support for duplicate detection and
   reordering to provide in-sequence delivery.

A.15. Evaluation Against Requirements PT-4

   Requirement PT-4 says:

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

   PT-EAP meets this requirement. The PT-EAP operates on top of
   the 802.1X and IKEv2 protocols.

A.16. Evaluation Against Requirements PT-5

   Requirement PT-5 says:

   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-EAP does NOT meet this requirement.  PT-EAP is intended for
   a different usage.  PT-EAP is intended to be used for pre-


Hanna                    Expires July 4, 2010                 [Page 39]

Internet-Draft                  PT-EAP                     January 2010


   network admission before the endpoint has been given an IP
   address and routes on the network.  This means that network
   layer protocols such as IP are not yet able to communicate with
   the system.  The PT-TLS (PT Binding to TLS) [11] meets this
   requirement.

A.17. Evaluation Against Requirements PT-6 (from PB-TNC specification)

   Requirement PT-6 says:

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

   PT-EAP meets this requirement.  The PT-EAP fits into the EAP
   framework which provides for orderly initiation and shutdown.

A.18. Evaluation Against Requirements PT-7 (from PB-TNC specification)

   Requirement PT-7 says:

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

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

A.19. Evaluation Against Requirements PT-8 (from PB-TNC specification)

   Requirement PT-8 says:

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

   PT-EAP meets this requirement.  The PT-EAP utilizes EAP's half
   duplex, round robin message exchange to provide flow and
   congestion control.

A.20. Evaluation Against Requirements PT-9 (from PB-TNC specification)

   Requirement PT-9 says:

   PT-9 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-EAP specification meets this requirement.  This
   specification discusses the level of transport service provided
   to the Posture Broker Client and Posture Broker Server.


Hanna                    Expires July 4, 2010                 [Page 40]

Internet-Draft                  PT-EAP                     January 2010


   Generally, the PT-EAP method supports the pre-network admission
   usages discussed in RFC 5209.  The maximum message size for PT-
   EAP is 2^16-10 octets.  EAP by its very nature is half duplex
   and very simple which allows it to be used in a wide variety of
   settings including over link layer protocols during the
   entrance to the network.

Authors' Addresses

   Steve Hanna
   Juniper Networks, Inc.
   79 Parsons Street
   Brighton, MA 02135 USA
   Email: shanna@juniper.net

   Paul Sangster
   Symantec Corporation
   6825 Citrine Drive
   Carlsbad, CA 92009 USA
   Email: paul_sangster@symantec.com





























Hanna                    Expires July 4, 2010                 [Page 41]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/