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 |