Re: [pcp] Stephen Farrell's No Objection on draft-ietf-pcp-authentication-13: (with COMMENT)

Hi Stephen,

Please see inline

> -----Original Message-----
> From: pcp [mailto:pcp-bounces@ietf.org] On Behalf Of Stephen Farrell
> Sent: Thursday, July 09, 2015 4:48 PM
> To: The IESG
> Cc: pcp@ietf.org
> Subject: [pcp] Stephen Farrell's No Objection on draft-ietf-pcp-authentication-
> 13: (with COMMENT)
> 
> Stephen Farrell has entered the following ballot position for
> draft-ietf-pcp-authentication-13: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-pcp-authentication/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> 
> Thanks for getting this done.
> 
> - Why didn't you choose to encrypt the PCP payloads after
> you've got a shared secret? If the answer here is "oops, we
> never thought about that," then this will likely turn into a
> DISCUSS, but I expect the WG did think about it, in which case
> I reckon my preference for confidentiality doesn't trump the WG
> consensus.

It was discussed in the PCP WG if PCP confidentiality is required and the outcome was encryption of PCP messages is not required.

> 
> - How would this work in a home network where the f/w is not
> managed by the ISP and there'd otherwise be no EAP
> infrastructure? 

Yes, PCP authentication cannot be used unless the home router supports local authentication.

> That could be out-of-scope or require some
> new/odd EAP implementation and no change to this protocol, and
> that is probably fine, but I do wonder.
> 
> - 3.3: Is this really needed? 

Yes, re-authentication requirement was discussed in the WG (REQ-4 in https://tools.ietf.org/html/draft-reddy-pcp-auth-req-04). 

> I wonder if we could do without
> it. The protocol would be simpler if this wasn't needed and
> simpler == more-secure in general.
> 
> - 5.11: would s/issued the credentials/issued the EAP
> credentials that will be used to authenticate the client/ be
> better? As-is, it's a tiny bit confusing maybe.

Thanks, updated draft.

> 
> - 6.2: Maybe this is being overly paranoid, but would it be
> worth saying that in all failure cases when you say discard the
> message, you mean to not process it's content?  

Yes, it means to stop processing the PCP message content.

> With a very
> perverse reading of the current text, I might be able to argue
> that I could process the message content first and only then
> check the authentication afterwards. Yes, that'd be fairly
> spectacularly dim, but that kind of thing does sometimes
> happen. (If there's a better place in the draft to put some
> text on that, that's just fine.)

Modified text in section 6.2 to say the following:
PCP device stops processing the PCP message and silently discards the message.

-Tiru

> 
> 
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp