Subject: [Nea] Fwd: APPSDIR review of draft-ietf-nea-pt-tls-04

From: Stephen Farrell <[email-masked]>
Date: Wed, 13 Jun 2012 12:32:16 +0100

Forwarding to nea list.

-------- Original Message --------
Subject: APPSDIR review of draft-ietf-nea-pt-tls-04
Date: Mon, 04 Jun 2012 20:01:40 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked], [email-masked]
CC: [email-masked]

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: Paul Sangster <[email-masked]>
Date: Wed, 13 Jun 2012 21:02:31 -0700

> -----Original Message-----
> From: Alexey Melnikov [mailto:[email-masked]]
> Sent: Monday, June 04, 2012 12:02 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]

[PS:] Since you weren't happy with our first attempt to address this comment, we would like to take you up on your kind offer to provide suggestions.  Maybe we could do this off-line and included the text in -06?

> instead instead of "Internet Standard". The same issue in the IANA

[PS:] This sentence will be re-written to address the gen-art comment so the new text won't have this issue.

> place, as you are not talking about SASL messages.

[PS:] Will make it more clear the relationship between SASL messages in PT-TLS and the SASL mechanism exchanges inside the messages.  The sentence mentioned is about the PT-TLS client authentication messages.

> just fails the authentication exchange. I suggest removing it as a

[PS:] This text was attempting to support the abort as described in RFC4422 which says:

3.5.  Aborting Authentication Exchanges

   A client or server may desire to abort an authentication exchange if
   it is unwilling or unable to continue (or enter into).

   A client may abort the authentication exchange by sending a message,
   the particulars of which are protocol specific, to the server,
   indicating that the exchange is aborted.  The server may be required
   by the protocol to return a message in response to the client's abort
   message.

   Likewise, a server may abort the authentication exchange by sending a
   message, the particulars of which are protocol specific, to the
   client, indicating that the exchange is aborted.

[PS]: Is this an unacceptable way to do this?  

> that they are always sent as 20 bytes, then this is missing from the

[PS:] Sure, word alignment would have been a good reason for doing this but we thought more about byte alignment.  We also thought having these bits available could be useful later (e.g. for indicating preference or some other semantic that could impact the mechanism selection).   Since we didn't need an entire byte for the Mech Len we thought it made sense to at least byte align the Mechanism Name and the cost of 3 bits for some future purpose made sense.

> returned instead of just Failure?

[PS:] The document gives the example of authentication failure (incorrect credential) where mechanism failure is when the mechanism logic detects a failure in processing the authentication request that isn't related to the user's input (e.g. malloc error).

> SASL Authentication result with Failure code?

[PS:] Hmm, I'm going to have to look into this more.  One way they are different is the fact that the NEA Client is not allowed to send the SASL Result TLV so can't use the Failure code but it could send a Failed Authentication error code in the PT-TLS Error Message.

> In 4.1.2, second block, the first bullet: I think you meant "client"

[PS:] Thanks, good catch

> In 6.2: is it possible to register a vendor specific value without a

[PS:] In order to be placed in the IANA registry a permanent specification is required (as mentioned in section 6.1).   Of course vendors are free to use values in their name space without registering them with the IANA.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 14 Jun 2012 22:01:05 +0100

Hi Paul,

> [PS:] Since you weren't happy with our first attempt to address this comment, we would like to take you up on your kind offer to provide suggestions.  Maybe we could do this off-line and included t…

Yes.

> [PS]: Is this an unacceptable way to do this?  

Well, Ok, but nobody is sending a special message when a SASL server wants to abort the exchange. Existing open source API don't seem to support this either.
I suppose the client can just treat this as an authentication failure, as it can't know what caused the abort.

> [PS:] Sure, word alignment would have been a good reason for doing this but we thought more about byte alignment.  We also thought having these bits available could be useful later (e.g. for indica…

Ok. Never mind.

Just to confirm: SASL mechanism names are not padded with spaces or NULs?

> [PS:] The document gives the example of authentication failure (incorrect credential) where mechanism failure is when the mechanism logic detects a failure in processing the authentication request…

Ok. Having malloc failure as an example would help.

> [PS:] Hmm, I'm going to have to look into this more.  One way they are different is the fact that the NEA Client is not allowed to send the SASL Result TLV so can't use the Failure code but it coul…

Wouldn't the client just send Abort in this case? (Abort makes sense for clients)
> [PS:] In order to be placed in the IANA registry a permanent specification is required (as mentioned in section 6.1).   Of course vendors are free to use values in their name space without register…

This might be a bit heavyweight and might discourage registrations. But if that is what you want...