Re: [Nea] PT-EAP I-D Ready for IESG Evaluation

["Nancy Cam-Winget (ncamwing)" <[e-mail]>]

Hi Stephen,

Thanks for your prompt and thorough review of the PT-EAP spec. I've
reviewed the comments that you sent and have provided further
comments/responses below.
If we can agree on all the updates/comments, I can churn another version
thenŠ.

Thanks again,

Nancy

P.S. The comments were very helpful :-)


On 11/18/12 6:45 PM, "Stephen Farrell" <[e-mail]> wrote:

>
>Hi Susan, all,
>
>My AD review of this is below. I'm not sure if the
>chairs/authors would prefer make changes and/or argue
>before IETF LC (either is fine), so I'll mark this as
>being in AD eval while we figure that out.
[NCW] As Steve mentioned in his earlier email, we'd like to
get these straightened out before we go to IETF LC.

>
>My first (numbered) list of questions are things I
>need to see answered before I start IETF LC. I'd say
>only question #1 might be tricky and its certainly
>ok to say that changes resulting from #2 & #3 will
>be put in after IETF LC, if some are needed, so
>#1 is (by far) the main deal.
>
>The other stuff you can consider as just some
>random-dude comments to take or leave:-)
>
>Cheers,
>S.
>
>questions I'd like answered before IETF LC:
>
>1) Doesn't the non-existence of a standards-track EAP outer
>method that meets the needs of NEA (section 5, 2nd para)
>mean that this draft ought stay in the RFC editor queue
>until TEAP is done, and that TEAP ought be MTI for PT-EAP?
>(Which could be easily done if the wg wanted it.)
>If the wg's answer to is "no, its ok now", then I'm
>confused, since you seem to require a standards track EAP
>outer method that does not exist. Wouldn't that imply that
>this protocol cannot be implemented as currently specified
>and wouldn't that be a bad outcome for the IETF?
[NCW] The NEA WG discussed this at length and agreed that the spec
should not wait for TEAP to be standardized.  There was consensus
that the already industry established/used tunnel methods, e.g. EAP-FAST,
EAP-TTLS and PEAP met the requirements in section 5 of PT-EAP; while
these are not standardized by the IETF, several of them are documented
in the IETF as informational RFCs. Further consensus indicated that the
group both, did not want to wait for TEAP's standardization and that there
would be some benefit if using the NEA protocols with the already existing
tunnel methods.

>
>2) 4.1.1: If the PTS trusts the PTC this way then its
>crazy! If this is saying that a PTS ought not include code
>to validate syntax then that'd be broken. What's wrong
>here? Seems like maybe its a case of putting in too many
>words? I think this 2nd bullet list in 4.1.1 might be
>better if it disappeared. I also think the last paragraph
>on 4.1.1 should also disappear. Is that unreasonable or ok?
[NCW] Your rationale makes sense and request is reasonable.
I think the intent was to provide a warning to the PTS implementations of
malicious PTC behaviors. Should we just include a sentence as such? E.g.
"Since the Posture Transport Server can not validate the trustworthiness
of the Posture Transport Client; the Posture Transport Server should
protect
itself accordingly."
Since 4.1.2 follows the same template, I presume you'd also like us to
follow
the same updates as we do for 4.1.1?

>
>3) 4.2.5, last para: on what basis can one say that an EMA
>is effective, other than by definition, which doesn't seem
>convincing? I do agree that some EMA implementation might
>be effective but not that all things calling themselves an
>EMA are effective. It therefore seems wrong to have text
>that appears to depend on the effectiveness of all EMAs.
[NCW] It is true that it is difficult to guarantee all EMA's
implementations to be effective.  Since there are some EMA's
believed to be effective as well as the charter stating
"the protocols developed by the NEA WG must be designed to accommodate
emerging technologies for identifying and dealing with lying endpoints",
the group felt that a SHOULD clause be included.


If there's "text that appears to depend on the effectiveness
of all EMAs", could you please point out the exact text so
that we can better address your concern?


>
>-----------------
>
>"random-dude" comments to take or leave:
>
>abstract: not sure if EAP needs expanding there or not
[NCW] Since it's the first reference, it does make sense to expand itŠso
will do.

>
>abstract: s/tunnel method/EAP tunnel method/ ?
[NCW] Thanks for the find!  Will doŠ

>
>intro: why does 1st sentence not use same terminology as
>abstract?
[NCW] No reason, so we'll make it consistent.

>
>intro: PB-TNC should be expanded
[NCW] OK. We'll also add a pointer to the PB-TNC reference.

>
>intro: it might be good to briefly explain the terms inner
>and outer for EAP methods, but only if that text is not
>going to be contentious.
[NCW] I don't think it would be contentious. We can put this in the last
paragraph
of section 1, which is the first place that we use the term
"inner EAP method".


>
>1.5: the forward-looking statement about what TCG might do
>in future seems out of place and was modified in the pt-tls
>draft I think. The same change seems right here.
[NCW] Sounds goodŠ.will do

>
>section 2: "MUST only" is odd, better would be to either
>s/only// or phrase this with a MUST NOT.
[NCW] OK, we can just remove "only"

>
>3.1: is the phrase "round robin exchange" clear or more
>confusing? It could be the latter since the term is mostly
>used in relation to load-balancing. That sentence is also
>pretty unclear, maybe what you mean is that there cannot be
>>1 PB-TNC batch in flight at any given time, if so, better
>to say so. I don't get the last sentence in the 3rd para
>here.
[NCW] We can change the sentence with round-robin from:

   The NEA Client and NEA Server then engage in a round-robin
   exchange with one PB-TNC batch in flight at a time.

to this:

   The NEA Client and NEA Server then take turns sending a
   PB-TNC batch. No more than one PB-TNC batch can ever be
   in flight at any given time.

It seems that the sentence you don't understand is this one:

   This message may be empty (not contain any data) if the NEA
   Server has just sent the last PB-TNC batch in the PB-TNC exchange.
Is that right? The preceding sentence was this one:

   The data transport phase always ends with an EAP Response
   message from the NEA Client to the NEA Server.

So the last message in the data transport phase goes from the
NEA Client to the NEA Server. If the NEA Client doesn't have
any PB-TNC batches to send, it just sends a PT-EAP message
whose Data field is empty. Does that help you understand what
we're trying to say? If so, perhaps we should change that
confusing sentence to say:

   The Data field of this message may have zero length if the NEA
   Server has just sent the last PB-TNC batch in the PB-TNC exchange.

>
>3.1: 3rd last and 2nd last paras are hard to get (at first
>reading at least).
[NCW] Sorry. The 3rd last para is just saying that the success of PT-EAP
does not mean that the overall authentication will succeed. Neither
does the failure of PT-EAP mean that the overall authentication will
fail. That depends on the policy configured by the administrator.
Maybe they're just doing a posture check to see which machines are
healthy for reporting purposes or maybe they don't keep unhealthy
machines off the network but quarantine them. This is not always
immediately clear to people when they read these specs.

The 2nd last para says that you don't have to continue the PT-EAP
exchange to the end. However, different EAP tunnel methods have
different ways to stop an inner EAP method prematurely. Any
suggestions for wording changes?

>
>3.1: last para seems unnecessary
[NCW] The intent was to ensure that the sequencing is followed (e.g. A
MUST).
Is that inferred by it being section 3 (e.g. A normative section?).  If
that's
the case, then we can remove the paragraph, otherwise, can you suggest how
we can ensure the sequencing if adhered to?

>
>3.3: It'd be good to give the figures names/captions to
>make 'em easier to reference.
[NCW] Sure will do (something new to learn in the xml script :-)

>
>3.3: 1st para, might be nice to name the 4 fields that are
>mandated. Also be good to say which of these fields are bog
>standard EAP and which are nea-specific, (in case someone
>codes up nea stuff to fit into some eap framwork or
>something). For example the start bit on p7 could be
>pt-eap-specific or not.
[NCW] Good point; will do.

>
>section 4: This entire section seems to fall between two
>stools. On the one hand it could be an ab-initio analysis
>of threats to a generic PT-EAP, or else if could be a
>post-facto analysis of residual threats that need to be
>countered given the final PT-EAP design. Its hard to tell
>which is intended and I think the text oscilates between
>the two. I think making sure that's crystal clear would
>help here, in terms of giving the reader an easier time.
[NCW] PT-EAP provides NO security protections at all.
All of the security is provided by the EAP tunnel method and
other components such as the EMA. So this sections attempts
to describe the threats relevant to PT-EAP (and the NEA
reference model) and translates those into a list of protections that the
EAP tunnel method must provide and a few things that the
PT-EAP implementer must do (e.g. be wary of data sent by
the other side and expose the tls-unique value upward).

Can you suggest ways to improve on what's written?


>
>4.1.1: I don't get what "not observe" means here. How can a
>piece of code send out some bytes that it has not
>"observed" in some sense?
[NCW] How about we change it to "Disclose to unauthorized parties"
instead?  The intent is to ensure that the PTC and PTS not leak the info.

>
>4.2, title is odd - what threat or countermeasure is
>nothing to do with security? suggest s/Security// in the
>title. (Same in 1st para of 4.2 and anywhere else.)
[NCW] OKŠwill do.

>
>4.2.1: I'm not sure what "theft" means in the title here -
>presumably is involves a bad actor doing more than just
>copying the bytes, but what, in general? Maybe change
>title to "message confidentiality"?
[NCW] SureŠwill do.

>
>4.2.1: who is "*the* adversary"? (my emphasis) Maybe
>s/the/an/
[NCW] SureŠwill do.


>
>4.2.1: "housed in" is an odd term likely to be easily
>misunderstood e.g. by non-native English speakers, "carried
>by" would seem better
[NCW] SureŠwill do.


>
>4.2.1: EAP-FAST and EAP-TTLS could do with references on
>first use.  (Same later for other methods, e.g. TEAP in
>4.2.3.)
[NCW] They are already referenced in Section 1; would you like us
To repeat them in this section as well?

>
>4.2.2: What'd it mean to creat a DoS against aspects of
>an assessment? I don't get that.
[NCW] One example would be to insert a PT-EAP message to
tell a NEA Server that the endpoint is totally infected.
This could cause the device to be blocked from accessing
a critical resource, which would be a denial of service.

>
>4.2.2: 1st para, malformed octets don't really seem like
>message fabrication.
[NCW] Would it be better to change it to the example above?

>
>4.2.2: last sentence - something wrong here, you can't
>say that unless you have an MTI outer EAP method that
>does guarantee that or else they all do, but do they
>all?
[NCW] If the EAP tunnel method meets the requirements in section 5,
it prevents undetected insertion of PT-EAP messages into a
properly authorized exchange. All of the EAP tunnel methods
described in section 4.3 meet those requirements. However,
it would be inappropriate to make one of them MTI for PT-EAP
because none of them is yet specified in a Standards Track RFC.

>
>4.2.3: last sentence - is this missing a 2119 REQUIRED?
[NCW] Some reviewers objected to putting RFC 2119 text into a Security
Considerations section. Therefore, we put all of the RFC 2119
requirements on EAP tunnel methods in section 5.



>
>4.2.4: "encrypted and hashed" is pretty imprecise.
[NCW] How about we split the sentence into:
"After the cryptographic authentication by the EAP tunnel method,
the session can be protected cryptographically to provide confidentiality
and source authenticity. Such protection prevents undetected
modification that could create a denial of service situation."


>
>4.3: I think if the use of TLS is significant then you
>need a reference to 5246. Maybe also 5280 but that could
>be implied by TLS.
[NCW] We do have a reference to RFC 5246. In fact, it's Normative.
TLS does permit PGP certificates to be used so it seems
wrong for us to reference RFC 5280.

>
>4.3: Is the parenthetic "using TLVs" text here stuff that
>ought go away? I think it probably is.
[NCW] SureŠwill do.

>
>section 6: the "MUST NOT observe" here seems like nonsense
>and nothing to do with 2119.
[NCW] SureŠwill do.

>
>7.1: is "PT-EAP Versions" a top-level registry or part of
>something else? I think you can answer this by saying
>what URL you think would be good for accessing this
>registry.
[NCW] It's Top levee registry.
>_______________________________________________
>Nea mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/nea