APPSDIR review of draft-ietf-nea-pt-tls-04

[Alexey Melnikov <[e-mail]>]

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