Subject: [secdir] sector review of draft-ietf-pcp-server-selection-07

From: Chris Inacio <[email-masked]>
Date: Sun, 4 Jan 2015 06:56:46 +0000

I have reviewed this document as part of the security directorate’s ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving security requirements and considerations in IETF drafts.  Comments not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

Generally the document is in good shape, and I would like to see one minor issue at least commented upon.

I have a single security related comment on this draft; the last sentence of section 3:

> For efficiency, the PCP client SHOULD use the same Mapping Nonce for
>   requests sent to all IP addresses belonging to the same PCP server.

Normally, I would simply say this is a crazy recommendation.  But after looking a little into what the Nonce is used for in the PCP protocol, I am slightly less distraught.  This Nonce does not appear to necessarily provide any huge amount of security except allowing the client to generate a unique token per PCP server.  Presumably there is a general MITM attack on the PCP protocol related to the Nonce as a transaction ID which is prevented by using other security protocols, TLS, etc.  (And another well known attack with the THIRD_PARTY option and lack of authentication…) Therefore, this Nonce is critical as a synchronization point between the client and the potential PCP server.  It would be nice (assuming all that is correct) to make that clear in the document, especially with a recommendation to reuse the Nonce.

Nits:

In Figure 1, the lines are not aligned to the “+” on the diagrams.

In Figure 3, “rtr1” is missing a “+” on the right side connection from the top.

--
Chris Inacio
[email-masked]

---

From: <[email-masked]>
Date: Mon, 5 Jan 2015 07:34:47 +0000

Dear Chris,

Thank you for the review. 

Nonce validation checks are used when operating in the simple threat model as discussed in RFC6887. Adding a reference to section 18.1 of RFC6887 would be sufficient IMHO. PCP authentication will be needed if operating in the Advanced Threat Model. 

OLD:
For efficiency, the PCP client SHOULD use the same Mapping Nonce for requests sent to all IP addresses belonging to the same PCP server. 

NEW:
 For efficiency, the PCP client SHOULD use the same Mapping Nonce for requests sent to all IP addresses belonging to the same PCP server. As a reminder, nonce validation checks are performed when operating in the Simple Threat Model (Section 18.1 of [RFC6887]) to defend against some off-path attacks.  

Better?

I already fixed the nits in my local copy.

Thank you.

Cheers,
Med

-----Message d'origine-----
De : Chris Inacio [mailto:[email-masked]] 
Envoyé : dimanche 4 janvier 2015 07:57
À : [email-masked]; [email-masked]; [email-masked]
Objet : sector review of draft-ietf-pcp-server-selection-07

Nits:

--
Chris Inacio
[email-masked]

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 5 Jan 2015 06:24:55 +0000

Hi Chris,

Thanks for the review. Please see inline

> -----Original Message-----
> From: Chris Inacio [mailto:[email-masked]]
> Sent: Sunday, January 04, 2015 12:27 PM
> To: [email-masked]; [email-masked]; draft-ietf-pcp-server-
> [email-masked]
> Subject: sector review of draft-ietf-pcp-server-selection-07
> 
> 
> 
> I have reviewed this document as part of the security directorate’s ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written with the intent of improving security requirements
> and considerations in IETF drafts.  Comments not addressed in last call may
> be included in AD reviews during the IESG review.  Document editors and WG
> chairs should treat these comments just like any other last call comments.
> 
> Normally, I would simply say this is a crazy recommendation.  But after
> looking a little into what the Nonce is used for in the PCP protocol, I am
> slightly less distraught.  This Nonce does not appear to necessarily provide
> any huge amount of security except allowing the client to generate a unique
> token per PCP server.  Presumably there is a general MITM attack on the PCP
> protocol related to the Nonce as a transaction ID which is prevented by using
> other security protocols, TLS, etc.  (And another well known attack with the
> THIRD_PARTY option and lack of authentication…) Therefore, this Nonce is
> critical as a synchronization point between the client and the potential PCP
> server.  It would be nice (assuming all that is correct) to make that clear in
> the document, especially with a recommendation to reuse the Nonce.

We will add the following text to Security considerations section to address this comment:
The Mapping Nonce value only provides protection against off-path attacks and PCP authentication [I-D.ietf-pcp-authentication] must 
be used to defend against man-in-the-middle attack.

> In Figure 3, “rtr1” is missing a “+” on the right side connection from the top.

Thanks, will fix the above nits in next revision.

Cheers,
-Tiru

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Mon, 5 Jan 2015 07:43:04 +0000

Hi Med,
Given that this is a recommendation for efficiency, we could perhaps
change 'SHOULD' to a 'MAY'.

We only introduced this because it's easier on the client to use the same
mapping nonce when it tries to connect with each address of the same
server in a sequential manner.

-Prashanth

On 1/5/15 1:04 PM, "[email-masked]"
<[email-masked]> wrote:

>Nonce validation checks are used when operating in the simple threat
>model as discussed in RFC6887. Adding a reference to section 18.1 of
>RFC6887 would be sufficient IMHO. PCP authentication will be needed if
>operating in the Advanced Threat Model.
>
>OLD:
>requests sent to all IP addresses belonging to the same PCP server. As a
>reminder, nonce validation checks are performed when operating in the
>Simple Threat Model (Section 18.1 of [RFC6887]) to defend against some
>off-path attacks. 
>
>Better?
>
>À : [email-masked]; [email-masked];
>[email-masked]
>I have reviewed this document as part of the security directorate¹s
>ongoing effort to review all IETF documents being processed by the IESG.
>These comments were written with the intent of improving security
>requirements and considerations in IETF drafts.  Comments not addressed
>in last call may be included in AD reviews during the IESG review.
>Document editors and WG chairs should treat these comments just like any
>other last call comments.
>
>looking a little into what the Nonce is used for in the PCP protocol, I
>am slightly less distraught.  This Nonce does not appear to necessarily
>provide any huge amount of security except allowing the client to
>generate a unique token per PCP server.  Presumably there is a general
>MITM attack on the PCP protocol related to the Nonce as a transaction ID
>which is prevented by using other security protocols, TLS, etc.  (And
>another well known attack with the THIRD_PARTY option and lack of
>authenticationŠ) Therefore, this Nonce is critical as a synchronization
>point between the client and the potential PCP server.  It would be nice
>(assuming all that is correct) to make that clear in the document,
>especially with a recommendation to reuse the Nonce.
>
>
>Nits:
>
>In Figure 1, the lines are not aligned to the ³+² on the diagrams.
>
>In Figure 3, ³rtr1² is missing a ³+² on the right side connection from
>the top.
>
>
>--
>Chris Inacio
>[email-masked]
>
>
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 5 Jan 2015 06:13:53 -0500

> change 'SHOULD' to a 'MAY'.

This would require a new WGLC.   I recommend against it: if the advice is good, it is good, and should be followed.   If it is not good, it should be removed.   The working group seemed to think it was good advice, so why change that now?   If you have a strong reason for changing it, I would of course support that, but I haven't heard one expressed.

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Mon, 5 Jan 2015 11:48:17 +0000

Hi Ted,
I don¹t have a strong reason, we don¹t need to change it.

-Prashanth

On 1/5/15 4:43 PM, "Ted Lemon" <[email-masked]> wrote:

>This would require a new WGLC.   I recommend against it: if the advice is
>good, it is good, and should be followed.   If it is not good, it should
>be removed.   The working group seemed to think it was good advice, so
>why change that now?   If you have a strong reason for changing it, I
>would of course support that, but I haven't heard one expressed.
>