A Posture Transport Protocol over TLS (PT-TLS)
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: RFC Editor <email@example.com>, nea mailing list <firstname.lastname@example.org>, nea chair <email@example.com> Subject: Protocol Action: 'PT-TLS: A TLS-based Posture Transport (PT) Protocol' to Proposed Standard (draft-ietf-nea-pt-tls-08.txt) The IESG has approved the following document: - 'PT-TLS: A TLS-based Posture Transport (PT) Protocol' (draft-ietf-nea-pt-tls-08.txt) as Proposed Standard This document is the product of the Network Endpoint Assessment Working Group. The IESG contact persons are Stephen Farrell and Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-nea-pt-tls/
Technical Summary PT-TLS is a protocol that carries NEA messages over TLS. By supporting a TLS transport, PT-TLS permits easy and efficient and monitoring of endpoint posture after an endpoint has been assigned an IP address. This contrasts with PT-EAP, which is more suitable for use before an endpoint has been assigned an IP address. Working Group Summary PT-TLS was carefully prepared and thoroughly reviewed within the NEA WG over a period of more than two years. After a call for proposals in October 2009, two proposals for a TLS-based transport were submitted to the NEA WG. The two were merged, taking the best features of each and removing unneeded features and elements. The resulting protocol received a careful review in the NEA WG including two WGLCs with comments from more than five people, some from industry and some from academia. There was clear WG consensus in favor of the resulting document with no cases of substantial disagreement. Document Quality While there are no known implementations of this exact protocol, NEA WG members have many years of implementation experience with other TLS-based posture protocols and brought their experience to bear in designing this protocol. Personnel The Document Shepherd is Steve Hanna. The Iresponsible Area Director is Stephen Farrell. RFC Editor Note Please delete the last paragraph of section 6, just before the start of 6.1 on the end of page 39. The paragraph to be deleted reads: This delegation of namespace is analogous to the technique used for OIDs. It can result in interoperability problems if vendors require support for particular vendor-specific values. However, such behavior is explicitly prohibited by this specification, which dictates that "Posture Transport Clients and Posture Transport Servers MUST NOT require support for particular vendor-specific PT-TLS Error Codes in order to interoperate with other PT-TLS compliant implementations (although implementations MAY permit administrators to configure them to require support for specific PT-TLS error codes)." Similar requirements are included for PT-TLS Message Types.