Subject: [pcp] PCP Proxy Authentication Requirements?

From: Ben McCann <[email-masked]>
Date: Tue, 11 Jun 2013 17:54:56 -0400

Req-9 in draft-reddy-pcp-auth-03 notes a PCP proxy must be able to 
validate message integrity and that it must be able to ensure message 
integrity if it modifies any fields in the message.

Doesn't this require authenticating the proxy to the PCP client and 
server because the proxy will need separate Security Associations to 
both the client and the server? I.e. without knowledge of the EAP Master 
Session Key, the proxy can't modify PCP packets w/o detection so it has 
to participate in the authentication process so it can form MSK's for 
both the client and the server. (I know, I'm assuming EAP is part of the 
authentication design).

Does Req-9 need clarification to note the presence of a proxy**requires 
*two *separately authenticated security associations? And, should the 
requirements permit authentication only on one side of the proxy? For 
example, a customer premises host may not authenticate to the PCP proxy 
but the proxy may authenticate to the PCP server?

On another topic...

There was substantial discussion on the list about two major PCP 
authentication architectures, *direct* *EAP-over-PCP *and *PANA*. I'm 
still catching up on the history of PCP authentication so forgive me if 
this question has been asked before/. /Are either of these protocols 
currently favored or has that discussion been tabled until the 
requirements are finalized?

I'm curious because PANA includes a secondary RFC (RFC 6345 
<http://tools.ietf.org/html/rfc6345>) which describes the operation of a 
relay agent between the PANA Client (PaC) and the PANA Authentication 
Agent (PAA). I don't think either of the PANA based approaches for PCP 
authentication (Side-by-Side or Tunneled) would be interoperable with a 
PANA relay agent.

If a PANA relay is required for a PANA deployment, and PCP was 
authenticated by PANA, then how would the PANA payloads embedded in PCP 
packets traverse the PANA relay? This is another area where PANA 
requires tweaking to support PCP authentication.

IMO, it is preferable to design an EAP transport within PCP because it 
can be purpose-built to address the specific requirements of PCP such as 
the PCP proxy. (Again, I assume EAP will be part of the PCP 
authentication protocol).

-Ben McCann

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Wed, 12 Jun 2013 14:47:15 +0000

Hi Ben,
Inline..

On 12/06/13 3:24 AM, "Ben McCann" <[email-masked]<mailto:[email-masked]>> wrote:

Req-9 in draft-reddy-pcp-auth-03 notes a PCP proxy must be able to validate message integrity and that it must be able to ensure message integrity if it modifies any fields in the message.

Doesn't this require authenticating the proxy to the PCP client and server because the proxy will need separate Security Associations to both the client and the server? I.e. without knowledge of the EAP Master Session Key, the proxy can't modify PCP packets w/o detection so it has to participate in the authentication process so it can form MSK's for both the client and the server. (I know, I'm assuming EAP is part of the authentication design).

<pra> Yes, the proxy has to authenticate with the PCP client and server with separate SAs.

Does Req-9 need clarification to note the presence of a proxy requires two separately authenticated security associations? And, should the requirements permit authentication only on one side of the proxy? For example, a customer premises host may not authenticate to the PCP proxy but the proxy may authenticate to the PCP server?

<pra> Yes, thats possible. We'll update the draft to spell this out more clearly.

-Prashanth

On another topic...

There was substantial discussion on the list about two major PCP authentication architectures, direct EAP-over-PCP and PANA. I'm still catching up on the history of PCP authentication so forgive me if this question has been asked before. Are either of these protocols currently favored or has that discussion been tabled until the requirements are finalized?

I'm curious because PANA includes a secondary RFC (RFC 6345<http://tools.ietf.org/html/rfc6345>) which describes the operation of a relay agent between the PANA Client (PaC) and the PANA Authentication Agent (PAA). I don't think either of the PANA based approaches for PCP authentication (Side-by-Side or Tunneled) would be interoperable with a PANA relay agent.

If a PANA relay is required for a PANA deployment, and PCP was authenticated by PANA, then how would the PANA payloads embedded in PCP packets traverse the PANA relay? This is another area where PANA requires tweaking to support PCP authentication.

IMO, it is preferable to design an EAP transport within PCP because it can be purpose-built to address the specific requirements of PCP such as the PCP proxy. (Again, I assume EAP will be part of the PCP authentication protocol).

-Ben McCann

---

From: <[email-masked]>
Date: Wed, 12 Jun 2013 22:24:40 +0000

I am responding to PANA-related questions.

Please see below.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Ben McCann
Sent: Wednesday, June 12, 2013 6:55 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [pcp] PCP Proxy Authentication Requirements?

On another topic...

There was substantial discussion on the list about two major PCP authentication architectures, direct EAP-over-PCP and PANA. I'm still catching up on the history of PCP authentication so forgive me if this question has been asked before. Are either of these protocols currently favored or has that discussion been tabled until the requirements are finalized?
[YO] My understanding is that the discussion has been tabled until the requirements are finalized.

I'm curious because PANA includes a secondary RFC (RFC 6345<http://tools.ietf.org/html/rfc6345>) which describes the operation of a relay agent between the PANA Client (PaC) and the PANA Authentication Agent (PAA). I don't think either of the PANA based approaches for PCP authentication (Side-by-Side or Tunneled) would be interoperable with a PANA relay agent.
If a PANA relay is required for a PANA deployment, and PCP was authenticated by PANA, then how would the PANA payloads embedded in PCP packets traverse the PANA relay? This is another area where PANA requires tweaking to support PCP authentication.
[YO] Although I believe those can be implementation specifics, first I would like to fully understand PCP proxy requirements.
Thanks,
Yoshihiro Ohba

-Ben McCann

---

From: Alper Yegin <[email-masked]>
Date: Thu, 13 Jun 2013 09:33:57 +0300

Hello,

> Does Req-9 need clarification to note the presence of a proxy requires two separately authenticated security associations? And, should the requirements permit authentication only on one side of the…

For the proxy to be able to modify the PCP packets and still maintain crypto-protection, we at least need two SAs: One between the PCP client and PCP proxy, and another between the PCP proxy and the PCP server. We could even talk about having a third one between the PCP client and the PCP server if we want to have a direct SA and identify some PCP payloads as untouchable by the proxy.

> I'm curious because PANA includes a secondary RFC (RFC 6345) which describes the operation of a relay agent between the PANA Client (PaC) and the PANA Authentication Agent (PAA). I don't think either of the PANA based approaches for PCP authentication (Side-by-Side or Tunneled) would be interoperable with a PANA relay agent.
> 

PANA relay and PCP proxy are two independent things. Having said that…. And PANA relay is an optional feature that is designed for a very special need  (see Zigbee IP).

Intro says:

   This document specifies PANA Relay Element (PRE) functionality, which
   enables PANA messaging between a PaC and a PAA where the two nodes
   cannot reach each other by means of regular IP routing.  For example,
   in ZigBee IP [ZIGBEEIP] that uses 6LoWPAN [RFC4944], a joining node
   (PaC) can only use a link-local IPv6 address to communicate with a
   parent node prior to PANA authentication.  The PAA typically resides
   in a 6LowPAN Border Router (6LBR) [6LoWPAN-ND], which is often
   multiple IP hops away from the PaC.  The PRE implemented on the
   parent node is used for relaying PANA messages between the PaC and
   the PAA in this scenario.

When PANA is carried inside PCP, PANA gets transported over PCP directly between the PCP client and the PCP server. 
I don't see the need to use PANA relay in this case. 

Alper

> -Ben McCann
> 
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp