I have been selected as the Applications Area Directorate reviewer for
this draft (for background on APPSDIR, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).
Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft. The review is not
copied to the IESG as the Last Call has not been announced yet.
Document: draft-ietf-nea-pt-tls-04
Title: PT-TLS: A TCP-based Posture Transport (PT) Protocol
Reviewer: Alexey Melnikov
Review Date: June 4, 2012
Summary: This document is almost ready for publication as a Proposed
Standard, although some [mostly] SASL related issues remain.
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.
(Note, I've reviewed -04, but I think all of this still applies to -05.)
Major:
In 3.4.2.1: RFC 6125 use details are missing. You need to describe
whether CN-IDs and SRV-IDs are allowed, whether wildcards are allowed,
etc. I can suggest some details.
Minor:
In Section 3.2: This document is not yet Internet Standard, it will be
Proposed Standard. Suggest saying "Publication on Standards Track"
instead instead of "Internet Standard". The same issue in the IANA
consideration section.
In 3.8.1: I think one instance of "SASL authentication messages" -->
"SASL authentication mechanisms". Otherwise this sentence is out of
place, as you are not talking about SASL messages.
In 3.8.4: in SASL the server doesn't return abort as an error code, it
just fails the authentication exchange. I suggest removing it as a choice.
In 3.8.7: you define the Reserved field which I assume is used for
padding? If yes, then you will not get proper alignment for the next
field, as SASL mechanism names are variable length. (If you intended
that they are always sent as 20 bytes, then this is missing from the
document.)
In 3.8.10:
The Abort choice is really not needed (as per above).
Also, can you give me an example of when the Mechanism Failure will be
returned instead of just Failure?
In 3.9: Failed Authentication error code - how does this differ from
SASL Authentication result with Failure code?
In 4.1.2, second block, the first bullet: I think you meant "client"
instead of the "server".
Question (might not be an issue):
In 6.2: is it possible to register a vendor specific value without a
specification?
The same question for 6.3.
Nits: None