attachment-0001
<br clear="all">Hi,<br><br>Equivalent TCG TNC spec to be announced same day as IETF RFC<br><br>Cheers,<br>- Ira<br><br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">The IESG</b> <span dir="ltr"><<a href="mailto:iesg-secretary@ietf.org">iesg-secretary@ietf.org</a>></span><br>
Date: Wed, Jan 2, 2013 at 3:46 PM<br>Subject: [Nea] Protocol Action: 'PT-TLS: A TLS-based Posture Transport (PT) Protocol' to Proposed Standard (draft-ietf-nea-pt-tls-08.txt)<br>To: IETF-Announce <<a href="mailto:ietf-announce@ietf.org">ietf-announce@ietf.org</a>><br>
Cc: nea mailing list <<a href="mailto:nea@ietf.org">nea@ietf.org</a>>, nea chair <<a href="mailto:nea-chairs@tools.ietf.org">nea-chairs@tools.ietf.org</a>>, RFC Editor <<a href="mailto:rfc-editor@rfc-editor.org">rfc-editor@rfc-editor.org</a>><br>
<br><br>The IESG has approved the following document:<br>
- 'PT-TLS: A TLS-based Posture Transport (PT) Protocol'<br>
(draft-ietf-nea-pt-tls-08.txt) as Proposed Standard<br>
<br>
This document is the product of the Network Endpoint Assessment Working<br>
Group.<br>
<br>
The IESG contact persons are Stephen Farrell and Sean Turner.<br>
<br>
A URL of this Internet Draft is:<br>
<a href="http://datatracker.ietf.org/doc/draft-ietf-nea-pt-tls/" target="_blank">http://datatracker.ietf.org/doc/draft-ietf-nea-pt-tls/</a><br>
<br>
<br>
<br>
<br>
Technical Summary<br>
<br>
PT-TLS is a protocol that carries NEA messages over TLS.<br>
By supporting a TLS transport, PT-TLS permits easy and<br>
efficient and monitoring of endpoint posture after an<br>
endpoint has been assigned an IP address. This contrasts<br>
with PT-EAP, which is more suitable for use before an<br>
endpoint has been assigned an IP address.<br>
<br>
Working Group Summary<br>
<br>
PT-TLS was carefully prepared and thoroughly reviewed<br>
within the NEA WG over a period of more than two years.<br>
After a call for proposals in October 2009, two proposals<br>
for a TLS-based transport were submitted to the NEA WG.<br>
The two were merged, taking the best features of each<br>
and removing unneeded features and elements. The resulting<br>
protocol received a careful review in the NEA WG including<br>
two WGLCs with comments from more than five people, some<br>
from industry and some from academia. There was clear WG<br>
consensus in favor of the resulting document with no cases<br>
of substantial disagreement.<br>
<br>
Document Quality<br>
<br>
While there are no known implementations of this exact<br>
protocol, NEA WG members have many years of implementation<br>
experience with other TLS-based posture protocols and brought<br>
their experience to bear in designing this protocol.<br>
<br>
Personnel<br>
<br>
The Document Shepherd is Steve Hanna. The Iresponsible Area<br>
Director is Stephen Farrell.<br>
<br>
RFC Editor Note<br>
<br>
Please delete the last paragraph of section 6, just before the<br>
start of 6.1 on the end of page 39. The paragraph to be<br>
deleted reads:<br>
<br>
This delegation of namespace is analogous to the technique used<br>
for OIDs. It can result in interoperability problems if<br>
vendors require support for particular vendor-specific values.<br>
However, such behavior is explicitly prohibited by this<br>
specification, which dictates that "Posture Transport Clients<br>
and Posture Transport Servers MUST NOT require support for<br>
particular vendor-specific PT-TLS Error Codes in order to<br>
interoperate with other PT-TLS compliant implementations<br>
(although implementations MAY permit administrators to<br>
configure them to require support for specific PT-TLS error<br>
codes)." Similar requirements are included for PT-TLS Message<br>
Types.<br>
<br>
<br>
_______________________________________________<br>
Nea mailing list<br>
<a href="mailto:Nea@ietf.org">Nea@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/nea" target="_blank">https://www.ietf.org/mailman/listinfo/nea</a><br>
</div><br>
<br />--
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.