One document matched: draft-cam-winget-eap-nea-tlv-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2434 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2434.xml">
<!ENTITY RFC3748 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml">
<!ENTITY RFC4493 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4493.xml">
<!ENTITY RFC5929 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5929.xml">
<!ENTITY RFC5793 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5793.xml">
<!ENTITY I-D.ietf-nea-pa-tnc SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nea-pa-tnc.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-cam-winget-eap-nea-tlv-02" ipr="pre5378Trust200902">
<front>
<title abbrev="EAP NEA TLV">EAP TLV for NEA</title>
<author fullname="Nancy Cam-Winget" initials="N" surname="Cam-Winget">
<organization abbrev="">Cisco Systems</organization>
<address>
<postal>
<street>80 West Tasman Drive</street>
<city>San Jose</city>
<country>US</country>
<code>95134</code>
<region>CA</region>
</postal>
<email>ncamwing@cisco.com</email>
</address>
</author>
<author fullname="Hao Zhou" initials="H" surname="Zhou">
<organization abbrev="">Cisco Systems</organization>
<address>
<postal>
<street>4125 Highlander Parkway</street>
<city>Richfield</city>
<country>US</country>
<code>44286</code>
<region>OH</region>
</postal>
<email>hzhou@cisco.com</email>
</address>
</author>
<date month="January" year="2011" />
<abstract>
<t> This document describes how Network Endpoint Assessment (NEA) data can be carried
inside of a general Type-Length-Value container using EAP-TLV. </t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>NEA has standardized a transport agnostic Posture Broker protocol defined
in <xref target="RFC5793"></xref> to effect a network endpoint assessment
between a Posture Broker Client and a Posture Broker Server. The Extensible Authentication
Protocol (EAP) <xref target="RFC3748"></xref> defines an authentication transport
mechanism that can be extended to transport the Posture Broker Protocol.
[draft-cam-winget-eap-tlv-01] defines an EAP-TLV
container to carry arbitrary data within an EAP method.</t><t>
This document describes an EAP-TLV that can be used to carry Posture Broker messages
within an EAP method.
This document also describes the capabilities and limitations of EAP as a transport mechanism for carrying NEA protocols. </t>
</section>
<section title="Specification Requirements">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref> .</t>
</section>
<section anchor="neaformat" title="EAP NEA TLV Format">
<t>The NEA EAP TLV Format is defined and described below. The fields are transmitted
from left to right.</t>
<figure>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved | PB-TNC Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Header | PB-PA Message... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| |
| PB-PA-Message... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list hangIndent="0" style="hanging">
<t><list hangIndent="3" style="hanging">
<t hangText="M"><vspace blankLines="1" /><list>
<t hangText="0">Optional TLV</t>
<t hangText="1">Mandatory TLV<vspace
blankLines="1" /></t>
</list></t>
<t hangText="R"><vspace blankLines="1" />Reserved, set to
zero (0)<vspace blankLines="1" /></t>
<t hangText="TLV Type"><vspace blankLines="1" /> The EAP NEA TLV type:
<vspace blankLines="1" /><list>
<t hangText="TBD"></t>
</list><vspace blankLines="1" /></t>
<t hangText="Length"><vspace blankLines="1" />The length of
the Value field in octets.<vspace blankLines="1" /></t>
<t hangText="Version"><vspace blankLines="1" />The one octet version of the
EAP NEA TLV: <vspace blankLines="1" /><list>
<t hangText="1"></t> </list> </t>
<t hangText="Reserved"><vspace blankLines="1" />Reserved octect, must
be set to 0x00<vspace blankLines="1" /></t>
<t hangText="PB-TNC Header"><vspace blankLines="1" /> The PB-TNC
encapsulation header as described in <xref target="RFC5793"></xref>.</t>
<t hangText="PB-PA Message"><vspace blankLines="1" /> The message between the
Posture Broker Client and Posture Broker Server as described in
<xref target="RFC5793"></xref>.</t>
</list></t></list></t>
</section>
<section anchor="Capabilities" title="Capabilities and Limitations of EAP-TLV as a PT for PB-TNC">
<t>TBD</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The EAP NEA TLV container carries network endpoint assessment information between
the Posture Broker Client and the Posture Broker Server. As some of this data can be sensitive,
it is highly recommended
that the EAP NEA TLV container MUST be carried inside a protected EAP tunneled method.</t>
<t> To address the potential man-in-the-middle attack in a tunneled EAP method, the 'tls-unique'
Channel Binding as defined in <xref target="RFC5929"></xref> MUST be used. </t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>The IANA is hereby requested to create a new registry for the
EAP NEA TLV defined in <xref target="neaformat"></xref>. The purpose
of this registry is uniquely identify when NEA Posture Broker Protocol packets
are being transported in an EAP method.</t>
</section>
<section title="Acknowledgements">
<t>The authors would like to recognize Joe Salowey, Susan Thomson,
Syam Appala and Subbu Srinivasan for providing input into this draft.</t>
</section>
</middle>
<!-- BACK MATTER *** -->
<back>
<references title="Normative References">
&RFC2119;
&RFC2434;
&RFC3748;
&RFC4493;
&RFC5929;
&RFC5793;
</references>
</back >
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 09:27:00 |