Subject: [pcp] wasserman-pcp-authentication

From: Alper Yegin <[email-masked]>
Date: Wed, 30 Nov 2011 12:07:23 +0200

I had given this comment at the meeting. Let me recap and solicit discussion on this:

Like the authors declare, this work is "largely based on PANA (RFC 5191)". 

In fact what it really does is, it decomposes RFC 5191 into pieces, imports them over and reassembles some sort of PANA within the PCP protocol. 

Instead of resurrecting PANA within PCP, I'd recommend we consider using PANA as-is alongside PCP. 

Running PANA between the end-points to dynamically generate a security association that can be used by PCP is the alternative I'd recommend. 

This is a better approach as it relies on re-use of protocols rather than creating new ones and has less impact on the PCP protocol.

Comments welcome.

Alper

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 30 Nov 2011 06:55:16 -0500

Hi Alper,

Without a more fleshed-out proposal, it is hard to understand exactly what you are suggesting.  Could you explain how the PANA authentication would be bound to a particular PCP request/response in this case, without modifications to the PCP client and server, similar to those described in our draft? 

Margaret

On Nov 30, 2011, at 5:07 AM, Alper Yegin wrote:

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

---

From: Alper Yegin <[email-masked]>
Date: Wed, 30 Nov 2011 19:25:26 +0200

Hi Margaret,

First, we run PANA between the end-points. That yields a PANA session -- with a session-id and a PANA SA.

Now that security association can be used with the PCP + your Authentication Tag Option.

That's it.

This split is a very common approach. Former is the so-called key management protocol (e.g., IKEv2, PANA, 802.1X), and the latter is where that key is used (e.g., IPsec, Zigbee, 802.11i).
 
Alper