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

[Stephen Farrell <[e-mail]>]

On the more nitty-bits...

On 11/27/2012 03:51 AM, Nancy Cam-Winget (ncamwing) wrote:
> 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 :-)

Great. But apologies for those that aren't:-)

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

See the other mail.

> 
>>
>> 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?

I think that'd be better. Maybe s/accordingly/appropriately/

>> 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?

I guess I meant this, from 3.4:

   If the
   tls-unique values of the NEA Client and NEA Server match and this is
   confirmed by the EMA, then the posture sent by the EMA (and thus the
   NEA Client) is from the same endpoint as the client side of the TLS
   connection (since the endpoint knows the tls-unique value) so no man-
   in-the-middle is forwarding posture.

The conclusion only holds for a "good" EMA, not for all EMAs. I guess
you could fix by s/sent by the EMA/sent by a trustworthy EMA/ or
similar.

>> -----------------
>>
>> "random-dude" comments to take or leave:

Just to repeat the above. Feel free to just cut off discussion
on these, we don't need to bottom out on any of this from my
p-o-v, unless you want to, in which case, I'm fine to chat
more.

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

That's better I think.

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

Ok, got it now (I think:-)

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

I think the text above would be useful to include maybe.

> 
> 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?

'Fraid not. But your explanations helped me.

> 
>>
>> 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?

Nope. I just think having RFC foo section bar say "you MUST follow
the protocol in this section" seems moot. No harm to leave it, other
than someone else may make the same comment, so it could consume
cycles;-)

>> 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?

Probably not - I'd only make it worse than it is now most
likely;-) This comment is probably better ignored.

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

Great.

> 
>>
>> 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?

Ah you're right. No, ignore me here too.

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

Good example thanks.

>> 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?

I think it would yes.

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

Sure. Maybe a forward pointer to section 5 would help.
(I mean it might help with reviewers, probably not that big
a deal for later readers of the 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.

Whatever. I agree some people say that kind of thing. They
are wrong. But fair enough. Better to s/required/needed/ if
you're taking that approach since REQUIRED is a 2119 keyword
(and 2119 doesn't really mandate upper case).

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

Nice.

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

Fair enough.

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

Might be good to say, or provide the URL you'd like to
help IANA get it right without having to ask.

Cheers,
S.


>> _______________________________________________
>> Nea mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nea
> 
> 
>