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

[Stephen Farrell <[e-mail]>]

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

Cheers,
S.

On 11/19/2012 10:37 PM, Stephen Hanna wrote:
> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Stephen Farrell
>> Sent: Sunday, November 18, 2012 9:45 PM
>> To: Susan Thomson (sethomso)
>> Cc: [e-mail]
>> Subject: Re: [Nea] PT-EAP I-D Ready for IESG Evaluation
>>
>>
>> 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.
>> _______________________________________________
>> Nea mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nea
> 
> 
> 
>