Subject: [apps-discuss] APPSDIR review of draft-ietf-nea-pt-tls-04

From: Alexey Melnikov <[email-masked]>
Date: Mon, 04 Jun 2012 20:01:40 +0100

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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 13 Jun 2012 11:47:14 +0100

> (Note, I've reviewed -04, but I think all of this still applies to -05.)
Additional issues in -05:

1) I didn't find the updated text prohibiting TLS renegotiation to be 
any clearer in -05? Can you maybe try to explain what is allowed and 
what is not?

2) In the IANA Considerations:

The PEN 0 (IETF) PT-TLS Message Type values between 9 and 2^32-2
inclusive are allocated for future assignment by the IANA.  The value
2^32-1 is permanently reserved and is not to be allocated.

Whom does the last sentence apply to? This registry? Or the IANA PEN 
registry being documented by draft-liang-iana-pen?

---

From: Paul Sangster <[email-masked]>
Date: Wed, 13 Jun 2012 21:11:17 -0700

> -----Original Message-----
> From: Alexey Melnikov [mailto:[email-masked]]
> Sent: Wednesday, June 13, 2012 3:47 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-nea-pt-tls-04
> 
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectora
> te
> > ).
> >

[PS:] The editors will discuss this more and provide a response.

> registry being documented by draft-liang-iana-pen?

[PS:] I'm assuming your asking about the text at the bottom of section 6.2. Registry for PT-TLS Message Types immediately below the table that defines registry values 0 thru 8 for PEN=0.  It refers to this specific registry not the PEN registry.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 14 Jun 2012 21:43:38 +0100

Hi Paul,

> [PS:] The editors will discuss this more and provide a response.

Thanks.

> [PS:] I'm assuming your asking about the text at the bottom of section 6.2. Registry for PT-TLS Message Types immediately below the table that defines registry values 0 thru 8 for PEN=0.  It refers…
Please make this clear in your document. If you want to reserve the 
value 2^32-1 in the PEN registry, then you need to make this clear in 
your document as well.