Skip to main content

A Posture Transport Protocol over TLS (PT-TLS)
draft-ietf-nea-pt-tls-08

Revision differences

Document history

Date Rev. By Action
2013-02-22
08 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2013-01-15
08 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2013-01-15
08 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2013-01-04
08 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent
2013-01-03
08 (System) IANA Action state changed to Waiting on Authors from In Progress
2013-01-02
08 (System) IANA Action state changed to In Progress
2013-01-02
08 Amy Vezza State changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed
2013-01-02
08 Amy Vezza IESG has approved the document
2013-01-02
08 Amy Vezza Closed "Approve" ballot
2013-01-02
08 Amy Vezza Ballot approval text was generated
2013-01-01
08 Stephen Farrell Ballot writeup was changed
2012-11-29
08 Cindy Morgan State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation
2012-11-29
08 Benoît Claise
[Ballot comment]
In the OPS-DIR Review by Nevil Brownlee on 20-Nov-2012, this comment was provided:

I have performed an Operations Directorate review of
  draft-ietf-nea-pt-tls-08.txt …
[Ballot comment]
In the OPS-DIR Review by Nevil Brownlee on 20-Nov-2012, this comment was provided:

I have performed an Operations Directorate review of
  draft-ietf-nea-pt-tls-08.txt

This is a Standards Track document, describing PT-TLS, "a TLS-based
Posture Transport (PT) protocol.  The PT-TLS protocol carries the
Network Endpoint Assessment (NEA) message exchange under the
protection of a Transport Layer Security (TLS) secured tunnel."

The document is quite long, and assumes that the reader is familiar
with Trusted Computing, Endoint Assessment, and with many acronyms
that I hadn't encountered before.  That meant that I also had to read
(or at least skim) quite a few of the of the Normative-Reference RFCs
before completing this review.  I suggest that an appendix listing
these acronyms and giving a few lines of explanation would be helpful.

The document is clearly intended to describe version 1 of PT-TLS,
but this is implied in section 3.7.1 rather than being explicitly stated.
Perhaps it would help to state this early on in section 3.5?

How will implementors find out that newer versions of PT-TLS exist?

The IANA Considerations section seems odd to me.  It says "This
delegation of namespace is analogous to the technique used for OIDs;"
which existing IANA Registry are you referring to?
Have you asked IANA whether they can support the two-dimensional
tables you're asking for?
2012-11-29
08 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2012-11-26
08 Roni Even Request for Telechat review by GENART Completed: Ready. Reviewer: Roni Even.
2012-11-26
08 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2012-11-21
08 Jean Mahoney Request for Telechat review by GENART is assigned to Roni Even
2012-11-21
08 Jean Mahoney Request for Telechat review by GENART is assigned to Roni Even
2012-11-19
08 Stephen Farrell State changed to IESG Evaluation from Waiting for AD Go-Ahead
2012-11-19
08 Stephen Farrell Telechat date has been changed to 2012-11-29 from 2012-08-30
2012-11-19
08 (System) State changed to Waiting for AD Go-Ahead from In Last Call
2012-11-15
08 Pearl Liang
IANA has reviewed draft-ietf-nea-pt-tls-08 and has the following comments:

IANA has a question about two of the IANA Actions requested in this document.

IANA understands …
IANA has reviewed draft-ietf-nea-pt-tls-08 and has the following comments:

IANA has a question about two of the IANA Actions requested in this document.

IANA understands that, upon approval of this document, there are three
IANA actions which must be completed.

First, IANA will make permanent the early allocated TCP port number 271 for use
with PT-TLS and change the reference to [ RFC-to-be ].

Second, the creation of a new registry is requested. This new registry will be
called "PT-TLS Message Types"

Each entry in this new registry will include a human-readable name, an SMI
Private Enterprise Number, a decimal integer value between 0 and 2^32-1, and a
reference to the specification where the contents of this message type are
defined.

IANA Question --> Do the authors intend that the top-level registry for this
newly requested PT-TLS registries is the registry 'Network Management
Parameters' located at http://www.iana.org/assignments/smi-numbers?

Management of this registry is done through Expert Review with Specification
Required as defined in RFC5226.

There are initial registrations as follows:

PEN Value Name Reference
--- ----- ---- ----------------------
0 0 Experimental [ RFC-to-be ]
0 1 Version Request [ RFC-to-be ]
0 2 Version Response [ RFC-to-be ]
0 3 SASL Mechanisms [ RFC-to-be ]
0 4 SASL Mechanism Selection [ RFC-to-be ]
0 5 SASL Authentication Data [ RFC-to-be ]
0 6 SASL Result [ RFC-to-be ]
0 7 PB-TNC Batch [ RFC-to-be ]
0 8 PT-TLS Error [ RFC-to-be ]
0 9-2^32-2 Future allocation [ RFC-to-be ]
0 2^32-1 Reserved [ RFC-to-be ]

Third, the creation of a new registry is requested. This new registry will be
called "PT-TLS Error Codes"

Each entry in this registry will include a human-readable name, an SMI Private
Enterprise Number, a decimal integer value between 0 and 2^32-1, and a reference
to the specification where this error code is defined.

IANA Question --> Do the authors intend that the top-level registry for this
newly requested PT-TLS registries is the registry 'Network Management
Parameters' located at http://www.iana.org/assignments/smi-numbers?

Management of this registry is done through Expert Review with Specification
Required as defined in RFC5226.

There are initial registrations as follows:

PEN Value Name Reference
--- ----- ---- ----------------------
0 0 Reserved [ RFC-to-be ]
0 1 Malformed Message [ RFC-to-be ]
0 2 Version Not Supported [ RFC-to-be ]
0 3 Type Not Supported [ RFC-to-be ]
0 4 Invalid Message [ RFC-to-be ]
0 5 SASL Mechanism Error [ RFC-to-be ]
0 6 Invalid Parameter [ RFC-to-be ]
0 7 - 2^32-1 Future Assignment [ RFC-to-be ]

IANA understands these three actions are the only ones required to be
completed upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
2012-11-05
08 Cindy Morgan
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (PT-TLS: A TLS-based Posture Transport (PT) …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (PT-TLS: A TLS-based Posture Transport (PT) Protocol) to Proposed Standard


The IESG has received a request from the Network Endpoint Assessment WG
(nea) to consider the following document:
- 'PT-TLS: A TLS-based Posture Transport (PT) Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-11-19. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

This second last call is caused by a late IPR declaration on the
document. (See the link below.)

Abstract


  This document specifies PT-TLS, a TLS-based Posture Transport (PT)
  protocol.  The PT-TLS protocol carries the Network Endpoint
  Assessment (NEA) message exchange under the protection of a
  Transport Layer Security (TLS) secured tunnel.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-nea-pt-tls/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-nea-pt-tls/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1890/



2012-11-05
08 Cindy Morgan State changed to In Last Call from Last Call Requested
2012-11-05
08 Stephen Farrell Last call was requested
2012-11-05
08 Stephen Farrell State changed to Last Call Requested from IESG Evaluation::AD Followup
2012-11-05
08 Stephen Farrell Last call announcement was changed
2012-11-05
08 Stephen Farrell Last call announcement was generated
2012-11-02
08 Sean Turner [Ballot comment]
I cleared.
2012-11-02
08 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss
2012-10-29
08 Sean Turner
[Ballot discuss]
Updated based on -08.  This is the remaining issue from the previous set of discusses.  Didn't see a response to this one or …
[Ballot discuss]
Updated based on -08.  This is the remaining issue from the previous set of discusses.  Didn't see a response to this one or changes based on it.

s3.9: Wouldn't it just be better to just send the message-id?  What are the cases where that's not enough?
2012-10-29
08 Sean Turner Ballot comment and discuss text updated for Sean Turner
2012-10-20
08 Barry Leiba [Ballot comment]
Version -08 handles all of my comments, and clears the IANA DISCUSS.  Thanks!
2012-10-20
08 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss
2012-10-20
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2012-10-20
08 Joseph Salowey New version available: draft-ietf-nea-pt-tls-08.txt
2012-10-04
(System) Posted related IPR disclosure: Cisco's Statement of IPR Related to draft-ietf-nea-pt-tls-07
2012-10-02
07 Roni Even Request for Telechat review by GENART Completed: Ready. Reviewer: Roni Even.
2012-09-20
07 Tero Kivinen Closed request for Telechat review by SECDIR with state 'No Response'
2012-08-30
07 Cindy Morgan State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation
2012-08-30
07 Adrian Farrel
[Ballot comment]
Comment updated after discussion of implementation status with
the document shepherd.

---

I think that the protocol is intended to transport Security Postures …
[Ballot comment]
Comment updated after discussion of implementation status with
the document shepherd.

---

I think that the protocol is intended to transport Security Postures
not any old postures. I would have benefited from a clear and early
definition of "Security Posture" - probably lifted from RFC 5209
although a citation might be enough.

I should have liked to see these issues clarified in the Abstract and
at the top of the Introduction.
2012-08-30
07 Adrian Farrel Ballot comment text updated for Adrian Farrel
2012-08-29
07 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy
2012-08-29
07 Adrian Farrel
[Ballot comment]
I like the write-up's description of the WG consensus, and it is clear
that there is support for this work. However, I am …
[Ballot comment]
I like the write-up's description of the WG consensus, and it is clear
that there is support for this work. However, I am disconcerted by the
statement "While there are no known implementations of this exact
protocol..." Can you explain what has been implemented and why it
differs from what is documented? Are there plans to migrate current
implementations to the documented protocol? Are there plans for new
implementations of the protocol?

---

I think that the protocol is intended to transport Security Postures
not any old postures. I would have benefited from a clear and early
definition of "Security Posture" - probably lifted from RFC 5209
although a citation might be enough.

I should have liked to see these issues clarified in the Abstract and
at the top of the Introduction.
2012-08-29
07 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2012-08-29
07 Barry Leiba
[Ballot discuss]
There's a problem with IANA's reading of the IANA Considerations, and have not seen any on-list discussion to correct that.  This DISCUSS, which …
[Ballot discuss]
There's a problem with IANA's reading of the IANA Considerations, and have not seen any on-list discussion to correct that.  This DISCUSS, which I'll copy to Pearl at IANA, is to make sure that's sorted out.

*** Please remove IANA from the CC list for any discussion that is NOT related to this point. ***

Pearl's note in the datatracker on 25 June says that they will use "Expert Review" for the policies for the two new registries (PT-TLS Message Types and PT-TLS Error Codes).  The document specifies "Specification Required" (but also uses the phrase "Designated Expert", which is what caused the confusion -- because Specification Required already includes the designation of an expert, there's no need to say that, and it only makes it more confusing for IANA).

The authors should please (1) reply to this to confirm that Specification Required is correct, and that IANA should note the change, and (2) change Section 6.1 as follows:

OLD
  For all of the IANA registries defined by this specification,
  new values are added to the registry by following the IANA
  Specification Required policy, using the Designated Expert
  process defined in RFC 5226 [RFC5226].

NEW
  For all of the IANA registries defined by this specification,
  new values are added to the registry by following the IANA
  Specification Required policy [RFC5226].

(And, by the way, thanks for including the excellent guidelines for the DE!)
2012-08-29
07 Barry Leiba Ballot discuss text updated for Barry Leiba
2012-08-29
07 Barry Leiba
[Ballot discuss]
There's a problem with IANA's reading of the IANA Considerations, and have not seen any on-list discussion to correct that.  This DISCUSS, which …
[Ballot discuss]
There's a problem with IANA's reading of the IANA Considerations, and have not seen any on-list discussion to correct that.  This DISCUSS, which I'll copy to Pearl at IANA, is to make sure that's sorted out.

Pearl's note in the datatracker on 25 June says that they will use "Expert Review" for the policies for the two new registries (PT-TLS Message Types and PT-TLS Error Codes).  The document specifies "Specification Required" (but also uses the phrase "Designated Expert", which is what caused the confusion -- because Specification Required already includes the designation of an expert, there's no need to say that, and it only makes it more confusing for IANA).

The authors should please (1) reply to this to confirm that Specification Required is correct, and that IANA should note the change, and (2) change Section 6.1 as follows:

OLD
  For all of the IANA registries defined by this specification,
  new values are added to the registry by following the IANA
  Specification Required policy, using the Designated Expert
  process defined in RFC 5226 [RFC5226].

NEW
  For all of the IANA registries defined by this specification,
  new values are added to the registry by following the IANA
  Specification Required policy [RFC5226].

(And, by the way, thanks for including the excellent guidelines for the DE!)
2012-08-29
07 Barry Leiba
[Ballot comment]
These are non-blocking, but please consider them seriously, and feel free to chat with me about them:

I agree with Russ that "PT-TLS: …
[Ballot comment]
These are non-blocking, but please consider them seriously, and feel free to chat with me about them:

I agree with Russ that "PT-TLS: A TLS-based Posture Transport (PT) Protocol" would be a better title (with corresponding change in the Abstract and Introduction).

I'm finding the PA/PB/PT combinations to be easy to mentally mangle, so any help in keeping them straight would be useful.  To that end, may I ask for this in Section 1?:

OLD
  The PT protocol in the NEA architecture [RFC5209] is responsible for
  transporting PB-TNC [RFC5793] batches (often containing PA-TNC
  [RFC5792] attributes) over the network between the Posture Transport
  Client component of the NEA Client and the Posture Transport Server
  component of the NEA Server.

NEW
  The Posture Transport protocol in the NEA architecture [RFC5209] is
  responsible for transporting Posture Broker (PB-TNC [RFC5793]) batches,
  often containing Posture Attributes (PA-TNC [RFC5792]), over the
  network between the Posture Transport Client component of the NEA
  Client and the Posture Transport Server component of the NEA Server.

(I would also be happy with shortening it to "PT Client" and "PT Server" at the end of the sentence, if "PT" is re-expanded at the beginning of the sentence like that.)
2012-08-29
07 Barry Leiba [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba
2012-08-29
07 Pete Resnick
[Ballot comment]
2119 language in IANA Considerations always gives me the creeps. I don't think the ones in section 6.1 are necessary:

  Instead, designated …
[Ballot comment]
2119 language in IANA Considerations always gives me the creeps. I don't think the ones in section 6.1 are necessary:

  Instead, designated experts should focus on the following
  requirements.  All values in these IANA registries MUST be
  documented in a specification that is permanently and publicly
  available. IETF namespace values MUST also be useful, not
  harmful to the Internet, and defined in a manner that is clear
  and likely to ensure interoperability.

I think both "MUST"s here could simply be lowercased, or change to "are required to".

  There are several ways to ensure that a specification is
  permanently and publicly available.  It may be published as an
  RFC.  Alternatively, it may be published in another manner that
  makes it freely available to anyone.  However, in this latter
  case, the vendor MUST supply a copy to the IANA and authorize
  the IANA to archive this copy and make it freely available to
  all if at some point the document becomes no longer freely
  available to all through other channels.

Here, better would be "will need to".
2012-08-29
07 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2012-08-29
07 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica
2012-08-29
07 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks
2012-08-28
07 Sean Turner
[Ballot discuss]
Well written.  Three discusses and some quibbles-n-bits.

Discuss:

1) s3.4.1.2: If you deny HTTP access during TLS Setup - I assume the HTTP/LDAP …
[Ballot discuss]
Well written.  Three discusses and some quibbles-n-bits.

Discuss:

1) s3.4.1.2: If you deny HTTP access during TLS Setup - I assume the HTTP/LDAP access is to support status checking (AIA/CRLDP/etc.) and denying it seems like a really bad idea.  A couple of points:

A) Need to add a security warning that says if access to status information is denied then clients won't have the necessary information to make an informed decision about the server's certificate.

B) Need to add some text that will ensure clients are prepared/configurable to proceed without status information.

C) There's also what you can do to fix this issue:

i) Deny the HTTP access but return the necessary information in the TLS handshake - i.e., using status_request or draft-ietf-tls-multiple-cert-status-extension-01?

ii) Better still: if you're in control of the certificate profile (you are aren't you) then you could just say don't include extensions that require auxiliary protocols because access via these other protocols may be denied, clients will have to proceed without status information, you're only making the certificate bigger because chances are the auxiliary protocols in these extension aren't going to allowed - and instead use the TLS mechanisms to get status info?

iii) Better still: provide a mechanism that will allow clients you've just blocked  from retrieving status information to ascertain whether the server is revoked later in the process with a TLV.  It's pending until you get the information needed to verify.  If it passes later - you're good - if not - fail the TLS connection.

2) Just trying to understand s3.8…s3.8.1 says the mechanism MUST at least support PLAIN SASL and then s3.8.3 says servers can indicate that no client authentication is required.  MUST clients support no authentication?  If that's the case then s3.8.1 needs to be updated to make that clearer.

3) s3.9: Wouldn't it just be better to just send the message-id?  What are the cases where that's not enough?
2012-08-28
07 Sean Turner
[Ballot comment]
Quibbles-n-bits:

s2.1: r/PA/Posture Attribute (PA) protocol

s3.1.1: trust root or trusted root or trust anchor?

s3.4.1.2: Being the impatient type I was about …
[Ballot comment]
Quibbles-n-bits:

s2.1: r/PA/Posture Attribute (PA) protocol

s3.1.1: trust root or trusted root or trust anchor?

s3.4.1.2: Being the impatient type I was about to ask what are the "other more cost effective methods" but they're in s3.8 - a pointer would be nice
2012-08-28
07 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded for Sean Turner
2012-08-28
07 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms
2012-08-28
07 Russ Housley
[Ballot comment]

  I would really like to see the title of this document updated.
  PT-TLS indicates that TLS must be used, but the …
[Ballot comment]

  I would really like to see the title of this document updated.
  PT-TLS indicates that TLS must be used, but the title indicates
  that TCP must be used.  I think the title should reflect that
  both TCP and TLS must be used.
2012-08-28
07 Russ Housley Ballot comment text updated for Russ Housley
2012-08-28
07 Russ Housley
[Ballot comment]

  I would really like to see the title of this document updated.  PT-TLS indicates that TLS
  must be used, but the …
[Ballot comment]

  I would really like to see the title of this document updated.  PT-TLS indicates that TLS
  must be used, but the title indicates that TCP must be used.  I think the title should
  reflect the needs for both TCP and TLS.
2012-08-28
07 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley
2012-08-28
07 Stewart Bryant
[Ballot comment]
I needed to get to the third para of the intro before I could find a reference to the definition of "Posture", it …
[Ballot comment]
I needed to get to the third para of the intro before I could find a reference to the definition of "Posture", it would be useful to quote the definition in this RFC and to move the reference to the first para.
2012-08-28
07 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant
2012-08-27
07 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2012-08-23
07 Jean Mahoney Request for Telechat review by GENART is assigned to Roni Even
2012-08-23
07 Jean Mahoney Request for Telechat review by GENART is assigned to Roni Even
2012-08-16
07 Martin Stiemerling
[Ballot comment]
a single comment:
It is worth noting in Section 3.1.1 that there can be also firewalls in the network which prevent the server …
[Ballot comment]
a single comment:
It is worth noting in Section 3.1.1 that there can be also firewalls in the network which prevent the server from reaching the client. The text describes only the case where the end device has a firewall.
2012-08-16
07 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2012-08-07
07 Paul Sangster New version available: draft-ietf-nea-pt-tls-07.txt
2012-07-21
06 Samuel Weiler Request for Telechat review by SECDIR is assigned to Sam Weiler
2012-07-21
06 Samuel Weiler Request for Telechat review by SECDIR is assigned to Sam Weiler
2012-07-20
06 Stephen Farrell Placed on agenda for telechat - 2012-08-30
2012-07-20
06 Stephen Farrell State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2012-07-20
06 Stephen Farrell Ballot has been issued
2012-07-20
06 Stephen Farrell [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell
2012-07-20
06 Stephen Farrell Created "Approve" ballot
2012-07-20
06 Stephen Farrell Ballot writeup was changed
2012-07-16
06 (System) Sub state has been changed to AD Followup from Revised ID Needed
2012-07-16
06 Paul Sangster New version available: draft-ietf-nea-pt-tls-06.txt
2012-06-25
05 Pearl Liang
IANA has reviewed draft-ietf-nea-pt-tls-05 and has the following comments:

IANA understands that, upon approval of this document, there are three
IANA actions which must be …
IANA has reviewed draft-ietf-nea-pt-tls-05 and has the following comments:

IANA understands that, upon approval of this document, there are three
IANA actions which must be completed.

First, the authors request a port assignment, for TCP only, for PT-TLS.
The authors should ubmit a template for early allocation and put
the Internet Draft as a reference according to RFC6335 as stated in
section 8.1.1:

IANA MAY accept early assignment [RFC4020 ]
requests (known as "early allocation" therein) from IETF working groups that
reference a sufficiently stable Internet-Draft instead of a published
Standards-Track RFC.

Second, the creation of a new registry is requested. This new registry will be
called "PT-TLS Message Types"

Each entry in this new registry will include a human-readable name, an SMI
Private Enterprise Number, a decimal integer value between 0 and 2^32-1,
and a reference to the specification where the contents of this message type
are defined.

Management of this registry is done through Expert Review as defined in RFC5226.

There are initial registrations as follows:

PEN Value Name Reference
--- ----- ---- ----------------------
0 0 Experimental [ RFC-to-be ]
0 1 Version Request [ RFC-to-be ]
0 2 Version Response [ RFC-to-be ]
0 3 SASL Mechanisms [ RFC-to-be ]
0 4 SASL Mechanism Selection [ RFC-to-be ]
0 5 SASL Authentication Data [ RFC-to-be ]
0 6 SASL Result [ RFC-to-be ]
0 7 PB-TNC Batch [ RFC-to-be ]
0 8 PT-TLS Error [ RFC-to-be ]
0 9-2^32-2 For future allocation [ RFC-to-be ]
0 2^32-1 Reserved [ RFC-to-be ]

Third, the creation of a new registry is requested. This new registry will be
called "PT-TLS Error Codes"

Each entry in this registry will include a human-readable name, an SMI Private
Enterprise Number, a decimal integer value between 0 and 2^32-1, and a reference
to the specification where this error code is defined.

Management of this registry is done through Expert Review as defined in RFC5226.

There are initial registrations as follows:

PEN Value Name Reference
--- ----- ---- ----------------------
0 0 Reserved [ RFC-to-be ]
0 1 Malformed Message [ RFC-to-be ]
0 2 Version Not Supported [ RFC-to-be ]
0 3 Type Not Supported [ RFC-to-be ]
0 4 Failed Authentication [ RFC-to-be ]
0 5 Invalid Message [ RFC-to-be ]
0 6 SASL Mechanism Error [ RFC-to-be ]
0 7 Invalid Parameter [ RFC-to-be ]
0 8 - 2^32-1 Future Assignment [ RFC-to-be ]

IANA understands these three actions are the only ones required to be
completed upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.
2012-06-13
05 Stephen Farrell State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead
2012-06-13
05 (System) State changed to Waiting for AD Go-Ahead from In Last Call
2012-06-07
05 Roni Even Request for Last Call review by GENART Completed. Reviewer: Roni Even.
2012-05-31
05 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2012-05-31
05 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2012-05-30
05 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (PT-TLS: A TCP-based Posture Transport (PT) …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (PT-TLS: A TCP-based Posture Transport (PT) Protocol) to Proposed Standard


The IESG has received a request from the Network Endpoint Assessment WG
(nea) to consider the following document:
- 'PT-TLS: A TCP-based Posture Transport (PT) Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-06-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies PT-TLS, a TCP-based Posture Transport (PT)
  protocol.  The PT-TLS protocol carries the Network Endpoint
  Assessment (NEA) message exchange under the protection of a Transport
  Layer Security (TLS) secured tunnel.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-nea-pt-tls/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-nea-pt-tls/ballot/


No IPR declarations have been submitted directly on this I-D.


2012-05-30
05 Amy Vezza State changed to In Last Call from Last Call Requested
2012-05-30
05 Stephen Farrell Last call was requested
2012-05-30
05 Stephen Farrell Ballot approval text was generated
2012-05-30
05 Stephen Farrell Ballot writeup was generated
2012-05-30
05 Stephen Farrell State changed to Last Call Requested from AD Evaluation::AD Followup
2012-05-30
05 Stephen Farrell Last call announcement was generated
2012-05-30
05 Stephen Farrell Last call announcement was generated
2012-05-29
05 (System) Sub state has been changed to AD Followup from Revised ID Needed
2012-05-29
05 Paul Sangster New version available: draft-ietf-nea-pt-tls-05.txt
2012-05-26
04 Stephen Farrell State changed to AD Evaluation::Revised ID Needed from AD Evaluation
2012-05-17
04 Stephen Farrell State changed to AD Evaluation from Publication Requested
2012-05-11
04 Cindy Morgan
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  …
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard is requested and indicated in the header.

PT-TLS is a protocol that permits NEA handshakes over TLS.
This is a common and well-established technique that has been
widely implemented in thousands of organizations using earlier
protocols. The desire here is to have a standard way to achieve
this goal so that vendor interoperability can be achieved. The
PT-TLS specification has been widely reviewed in the NEA WG and
is based on broad implementation experience with earlier protocols.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

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 Responsible Area
  Director is Stephen Farrell.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The Document Shepherd has carefully reviewed this document
and believes that it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

No concerns. The document has been carefully and thoroughly
reviewed by many NEA WG members.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Broader review is always welcome but no particular type of
expert review is known to be needed.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns. There's clearly a need for this document as
it provides a standard way to perform a common operation:
carrying endpoint posture information over TLS. And this
protocol has been carefully developed within the NEA WG
and achieved consensus there.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

There is strong consensus for this document within
the NEA WG. Two WGLCs and years of discussion of
the document show unanimous support across a large
number of WG participants.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246)

PT-TLS says:

  Implementations of PT-TLS MUST support use of TLS 1.1 [RFC4346] and
  SHOULD also include support for TLS 1.2 [RFC5246].

We have been assured that this is permitted since most
TLS implementations today do not support TLS 1.2.

  -- No information found for draft-ietf-nea-pt-eap - is the name correct?

PT-TLS includes a reference to draft-ietf-nea-pt-eap-01.txt.
I think that idnits is complaining because the draft name
is split across two lines.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Not applicable.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No such references exist. All normative references are to BCPs
or Standards Track RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

No. All normative references are to BCPs or Standards Track RFCs.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No, this document does not change the status of any
existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

I have reviewed the IANA Considerations section for all of these
issues and can confirm that it complies and is clearly written.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

This document defines two new IANA registries: PT-TLS Message Types
and PT-TLS Error Codes. Both of them require Expert Review with
Specification Required. In selecting the experts for these registries,
the IESG should look for people with good judgment and IETF experience.
People with experience with PT-TLS and/or other NEA protocols should
be preferred. If such people are not available, people with security
protocol expertise should be preferred.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

Not applicable. None of this document is written in a formal language.
2012-05-11
04 Cindy Morgan Note added 'Steve Hanna (shanna@juniper.net) is the document shephrd.'
2012-05-11
04 Cindy Morgan Intended Status changed to Proposed Standard
2012-05-11
04 Cindy Morgan IESG process started in state Publication Requested
2012-05-11
04 (System) Earlier history may be found in the Comment Log for draft-sangster-nea-pt-tls
2012-05-09
04 Paul Sangster New version available: draft-ietf-nea-pt-tls-04.txt
2012-04-26
03 Paul Sangster New version available: draft-ietf-nea-pt-tls-03.txt
2012-03-08
02 Paul Sangster New version available: draft-ietf-nea-pt-tls-02.txt
2011-09-19
01 (System) New version available: draft-ietf-nea-pt-tls-01.txt
2011-06-13
00 (System) New version available: draft-ietf-nea-pt-tls-00.txt