Skip to main content

Port Control Protocol (PCP) Authentication Mechanism
draft-ietf-pcp-authentication-14

Yes

(Brian Haberman)

No Objection

(Alia Atlas)
(Alissa Cooper)
(Alvaro Retana)
(Barry Leiba)
(Ben Campbell)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Kathleen Moriarty)
(Martin Stiemerling)
(Spencer Dawkins)

Note: This ballot was opened for revision 12 and is now closed.

Brian Haberman Former IESG member
Yes
Yes (for -12) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -13) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -13) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -13) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (for -13) Unknown

                            
Ben Campbell Former IESG member
No Objection
No Objection (for -13) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (2015-07-06 for -13) Unknown
Thanks for addressing Jouni's OPS DIR review.
Deborah Brungard Former IESG member
No Objection
No Objection (for -13) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -13) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -13) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (for -13) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -13) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -13) Unknown

                            
Stephen Farrell Former IESG member
(was Discuss, No Objection) No Objection
No Objection (2015-07-09 for -13) Unknown

Thanks for getting this done.


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

- 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?  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.)
Terry Manderson Former IESG member
No Objection
No Objection (2015-07-07 for -13) Unknown
Thanks for addressing an aspect of security in relation to PCP, especially the Advanced Threat Model from RFC6887.

I have a few comments

1) I'm sure the RFC editor will pick these up, however there is some comma usage in the document that caused me to re-read some of the paragraphs to understand. The Abstract is one example of this. I'm certainly no expert so perhaps have a skim over this: http://www.grammarbook.com/punctuation/commas.asp

2) s 3.1.1, please consider rewording the text "Section 5.1 updates the PCP request message format to have a result code." to something like "Section 5.1 updates the PCP request message format with result codes for the PCP Authentication mechanism" ...The wording as it stands seems a little non-specific.

3) Basic DoS attacks (such as state bloat) are mentioned in the security section, are there any complex DoS attacks that can be leveraged using the PCP authentication mechanism itself?