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

From: "Susan Thomson (sethomso)" <[email-masked]>
Date: Thu, 15 Nov 2012 01:57:42 +0000

Stephen

The PT-EAP I-D (draft-ietf-nea-pt-eap-05.txt) has completed WG Last Call and is ready for IESG evaluation as Proposed Standard.

I am document shepherd and the write-up is attached.

Thanks
Susan

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 Nov 2012 10:07:27 +0000

Thanks Susan,

I'll get the AD review back to you soon's I can.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 19 Nov 2012 02:45:03 +0000

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.

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?

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?

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.

-----------------

"random-dude" comments to take or leave:

abstract: not sure if EAP needs expanding there or not

abstract: s/tunnel method/EAP tunnel method/ ?

intro: why does 1st sentence not use same terminology as
abstract?

intro: PB-TNC should be expanded

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.

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.

section 2: "MUST only" is odd, better would be to either
s/only// or phrase this with a MUST NOT.

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.

3.1: 3rd last and 2nd last paras are hard to get (at first
reading at least).

3.1: last para seems unnecessary

3.3: It'd be good to give the figures names/captions to
make 'em easier to reference.

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.

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.

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?

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

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

4.2.1: who is "*the* adversary"? (my emphasis) Maybe
s/the/an/

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

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

4.2.2: What'd it mean to creat a DoS against aspects of
an assessment? I don't get that.

4.2.2: 1st para, malformed octets don't really seem like
message fabrication.

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?

4.2.3: last sentence - is this missing a 2119 REQUIRED?

4.2.4: "encrypted and hashed" is pretty imprecise.

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.

4.3: Is the parenthetic "using TLVs" text here stuff that
ought go away? I think it probably is.

section 6: the "MUST NOT observe" here seems like nonsense
and nothing to do with 2119.

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.

---

From: Stephen Hanna <[email-masked]>
Date: Mon, 19 Nov 2012 22:37:18 +0000

Stephen,

Thanks for your prompt review and solid comments. I have
talked with Susan and with the spec editors. We agreed
that it's best to address your suggestions before we send
the document off for IETF Last Call. Otherwise, we'd just
be wasting the time of IETF Last Call participants because
they'd be reviewing a document that wasn't quite done yet.

The spec editors are working up a response now and should
have it for you shortly.

Thanks,

Steve

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stephen Farrell
> Sent: Sunday, November 18, 2012 9:45 PM
> To: Susan Thomson (sethomso)
> Cc: [email-masked]
> Subject: Re: [Nea] PT-EAP I-D Ready for IESG Evaluation
> 
> 
> Hi Susan, all,
> 
> _______________________________________________
> Nea mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nea

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 19 Nov 2012 22:46:17 +0000

Thanks Steve, I've marked this as revised I-D needed
and look forward to the editors' response,

Cheers,
S.

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Tue, 27 Nov 2012 03:51:16 +0000

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

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

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

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

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

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

>and outer for EAP methods, but only if that text is not
[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".

>draft I think. The same change seems right here.
[NCW] Sounds goodŠ.will do

>s/only// or phrase this with a MUST NOT.
[NCW] OK, we can just remove "only"

>to say so. I don't get the last sentence in the 3rd para
[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
[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?

>make 'em easier to reference.
[NCW] Sure will do (something new to learn in the xml script :-)

>something). For example the start bit on p7 could be
[NCW] Good point; will do.

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

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

>title. (Same in 1st para of 4.2 and anywhere else.)
[NCW] OKŠwill do.

>title to "message confidentiality"?
[NCW] SureŠwill do.

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

>misunderstood e.g. by non-native English speakers, "carried
[NCW] SureŠwill do.

>first use.  (Same later for other methods, e.g. TEAP in
[NCW] They are already referenced in Section 1; would you like us
To repeat them in this section as well?

>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
[NCW] Would it be better to change it to the example above?

>does guarantee that or else they all do, but do they
[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."

>need a reference to 5246. Maybe also 5280 but that could
[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.

>ought go away? I think it probably is.
[NCW] SureŠwill do.

>and nothing to do with 2119.
[NCW] SureŠwill do.

>what URL you think would be good for accessing this
[NCW] It's Top levee registry.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 Nov 2012 10:48:01 +0000

Hi Nancy,

Thanks for that. Just splitting out the one non-nit thing, I'll
respond to the rest in a bit.

> would be some benefit if using the NEA protocols with the already existing

Ok, good to have this recently documented.

I guess the issue is that that plan leaves PT-EAP not really
conforming with BCP 61 (the one that says you MUST almost always
have strong security as MTI). [1] I'm sure that'll be a topic
for discussion during IESG evaluation, so best if we're explicit
about it now so we can point at this thread for the IESG.
(Apologies for rehashing the WG discussion, but I reckon
it'll be useful for the IESG.)

I reckon the following options exist in principle.

1) Process PT-EAP as-is and have the discussion about BCP61
with the IESG. I guess the WG argument here is in section 5
of the document where it says that the outer EAP method
MUST do what's needed and points at TEAP.

2) Pick one of the existing EAP methods and make that MTI.
We can handle the downref in the IETF LC, so that's not
an issue, if there's an existing method that would work for
the WG. The draft could also say that we expect folks to
migrate to a standards-track method in future.

3) The WG could change its mind and decide to wait on TEAP
if the situation has moved on since this was discussed before.

The draft takes approach #1, so unless you (the WG) want to
change your mind I'm ok with progressing this on that basis,
but we may need to have the discussion with the IESG.

So, no response is needed to this, unless folks want to
plump for #2 or #3 or something else.

Thanks,
S.

[1] http://tools.ietf.org/html/bcp61

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 Nov 2012 11:50:21 +0000

On the more nitty-bits...

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

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

> would be some benefit if using the NEA protocols with the already existing

See the other mail.

> the same updates as we do for 4.1.1?

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

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

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.

>    in flight at any given time.

That's better I think.

>    Server has just sent the last PB-TNC batch in the PB-TNC exchange.

Ok, got it now (I think:-)

> immediately clear to people when they read these specs.

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

> suggestions for wording changes?

'Fraid not. But your explanations helped me.

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

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

> instead?  The intent is to ensure that the PTC and PTS not leak the info.

Great.

> To repeat them in this section as well?

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

> a critical resource, which would be a denial of service.

Good example thanks.

> [NCW] Would it be better to change it to the example above?

I think it would yes.

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

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

> modification that could create a denial of service situation."

Nice.

> wrong for us to reference RFC 5280.

Fair enough.

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

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 28 Nov 2012 18:23:32 +0000

The TEAP work in EMU is progressing well.  I think it is realistic for the document to go to the IESG before the next IETF.  I think participation from the NEA working group would even help accelerate the progress.   I think that previously that working group was concerned that the tunnel method work would lag too far behind the PT-EAP method when making the choice to not specify an MTI.  

So I think 3) would be the best option, one might be OK if it is acceptable to the IESG.  

If a few folks on the NEA list could commit to doing a review of the TEAP document that would help mode things along. I believe its in the the best interest of the NEA group to review the document at this point to make sure that it will meet your needs.  The latest revision is available here:

http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-04

Let me know if you can review.  

Thanks,

Joe

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Wed, 28 Nov 2012 18:43:41 +0000

I agree with Joe; with the timing now, TEAP is very close to completion
and may complete at the same time as PT-EAP so
Option #3 would be the best option at this time.

Šwould also be good to get TEAP review from NEA participants!

Thanks, Nancy.

On 11/28/12 10:23 AM, "Joseph Salowey (jsalowey)" <[email-masked]>
wrote:

>The TEAP work in EMU is progressing well.  I think it is realistic for
>the document to go to the IESG before the next IETF.  I think
>participation from the NEA working group would even help accelerate the
>progress.   I think that previously that working group was concerned that
>the tunnel method work would lag too far behind the PT-EAP method when
>making the choice to not specify an MTI.
>
>If a few folks on the NEA list could commit to doing a review of the TEAP
>document that would help mode things along. I believe its in the the best
>interest of the NEA group to review the document at this point to make
>sure that it will meet your needs.  The latest revision is available here:
>

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 29 Nov 2012 14:50:57 +0000

Certainly there's a lot to be said for having a complete top-to-bottom
set of MTI protocols. I'm OK with option #3 if we can request early
allocation of the EAP Method type for PT-EAP from IANA and if we permit
using other EAP tunnel methods with PT-EAP. This should allow people to
start implementing and testing PT-EAP now, while the EMU WG is putting
the final touches on TEAP. There are several people who would like to
get started on implementing PT-EAP and gaining operational experience
with it. That's a good thing and we should encourage it!

Thanks,

Steve

> Nancy Cam-Winget (ncamwing)
> Sent: Wednesday, November 28, 2012 1:44 PM
> To: Joseph Salowey (jsalowey); Stephen Farrell
> Cc: [email-masked]
> Subject: Re: [Nea] MTI EAP outer method (was: Re: PT-EAP I-D Ready for
> IESG Evaluation)
> 
> >>> group both, did not want to wait for TEAP's standardization and
> that
> >>>there

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 29 Nov 2012 15:11:36 +0000

> with it. That's a good thing and we should encourage it!

Great. If the WG are ok with that I think it'd be a better
outcome.

On the registration, I see [1] EAP methods 1-191 are specification
required and 191-255 are "standards action." I'm not sure what's
the intent there, but presumably we can ask the DE to ok it and
get an early registration since PT-EAP is a WG document. Maybe
Joe can clarify? (And Joe, are you the designated expert as EMU
chair?)

Cheers,
S.

[1]
http://www.iana.org/assignments/eap-numbers/eap-numbers.xml#eap-numbers-3

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 29 Nov 2012 17:44:06 +0000

> Joe can clarify? (And Joe, are you the designated expert as EMU

[Joe] I think I used to be, I haven't seen requests recently for EAP-methods that have not gone through the IETF process so I'm not sure if I am still the designated expert or not.  I don't see a problem with early registration.