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

Alexey Melnikov <> Mon, 04 June 2012 19:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 57D0221F84A7; Mon, 4 Jun 2012 12:01:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.396
X-Spam-Status: No, score=-102.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jlaSY1KxXsgv; Mon, 4 Jun 2012 12:01:48 -0700 (PDT)
Received: from ( [IPv6:2a00:14f0:e000:7c::2]) by (Postfix) with ESMTP id 3BC8111E80BC; Mon, 4 Jun 2012 12:01:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1338836507;; s=selector;; bh=vxo9UNRHNXKosweE/7BBzhB8IVZ0Ll8Zii4qOOSGJOI=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=DXUlY8hlueWQ6af40iOP9KQgx8xRYhMglblOtCsSfTEVgIH/5XQ9vNCIi+Q3t0jST+zzz1 IZRrs48uXe9Saf2mZOTMIJMu4nBhjJ4iOWoknM8eyz7fJjbc8qfXd4DGj+KUW12F2N9478 U4LUNjEBo0gs6MJIx8BuWWC0PjxDN6Y=;
Received: from [] ((unknown) []) by (submission channel) via TCP with ESMTPSA id <>; Mon, 4 Jun 2012 20:01:44 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <>
Date: Mon, 04 Jun 2012 20:01:40 +0100
From: Alexey Melnikov <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
Subject: APPSDIR review of draft-ietf-nea-pt-tls-04
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Jun 2012 19:01:49 -0000

I have been selected as the Applications Area Directorate reviewer for 
this draft (for background on APPSDIR, please see ).

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.)


In 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.


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 

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 

The same question for 6.3.

Nits: None