Subject: Re: [pcp] About selecting a key management for PCP

From: "Dan Wing" <[email-masked]>
Date: Wed, 1 Aug 2012 13:26:24 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Zhangdacheng (Dacheng)
> Sent: Tuesday, July 31, 2012 3:51 AM
> To: [email-masked]
> Cc: Margaret Wasserman
> Subject: [pcp] About selecting a key management for PCP
> 
> Hi, All:
> 
> We have a discussion about the selection of a key management mechanism
> for PCP, but there is not a conclusion yet. Basically, people focus on
> two solutions, using PANA or generating an in-band authenticaiton
> mchanism for PCP (actually a simplified PANA). Now, there is a new
> draft draft-ohba-pcp-pana-00, which tries to specify the first one. So,
> maybe it is the right time to raise this disucssion again and decide
> the key management solution for PCP eventually.

Yes, we need to conclude on the PCP authentication mechanism.  

I have high hopes for the comparison of approaches that is in PCP's 
agenda, https://datatracker.ietf.org/meeting/84/agenda/pcp,

  1555-xxxx Comparison of PCP Authentication approaches (Margaret Wasserman,
??)
    Document: draft-ietf-pcp-authentication-00

-d

---

From: Alper Yegin <[email-masked]>
Date: Thu, 2 Aug 2012 15:32:06 +0300

> an in-band authenticaiton mchanism for PCP (actually a simplified PANA).

It's not simplified…. It's basically growing PANA (an EAPoUDP transport) within PCP. A redundant work that'd result in more complexity than keeping two simple protocols separate. This "oh I'll just carry EAP over my favorite protocol (e.g., DHCP!), and it'd be sooo simple" was tried before and failed miserably.  PCP and its key management are two separate issues that deserve two separate protocols (similar to IKE and IPsec being separate). I don't see any value in cobbling them up, which is more like a PPP-style approach -- all-in-one. 

Alper

On Jul 31, 2012, at 1:50 PM, Zhangdacheng (Dacheng) wrote:

> Hi, All:
> 
> We have a discussion about the selection of a key management mechanism for PCP, but there is not a conclusion yet. Basically, people focus on two solutions, using PANA or generating an in-band authenticaiton mchanism for PCP (actually a simplified PANA). Now, there is a new draft draft-ohba-pcp-pana-00, which tries to specify the first one. So, maybe it is the right time to raise this disucssion again and decide the key management solution for PCP eventually.
> 
> Cheers
> 
> Dacheng
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Thu, 2 Aug 2012 14:56:51 +0000

________________________________________
发件人: Alper Yegin [[email-masked]]
发送时间: 2012年8月2日 20:32
到: Zhangdacheng (Dacheng)
Cc: [email-masked]; Margaret Wasserman
主题: Re: [pcp] About selecting a key management for PCP

>It's not simplified…. It's basically growing PANA (an EAPoUDP transport) within PCP. A redundant work that'd >result in more complexity than keeping two simple protocols separate. This "oh I'll just carry EAP over my favorite >protocol (e.g., DHCP!), and it'd be sooo simple" was tried before and failed miserably.  PCP and its key >management are two separate issues that deserve two separate protocols (similar to IKE and IPsec being >separate). I don't see any value in cobbling them up, which is more like a PPP-style approach -- all-in-one.

Maybe my bad English causes confusion. Sorry for that. The "simplified" here means we can remove the redundant functions of PANA and only keep the necessary part. That is exactly what we are trying to do in the pcp authentication draft.

In addition, you remind me one thing. Karp WG is trying to use IKEv2 to provide key management for unicast routing protocols. If our WG decide to select a seperated AKM solution. Do you think it is a good idea to borrow their work to secure PCP?

Cheers

Dacheng

Alper

---

From: Alper Yegin <[email-masked]>
Date: Fri, 3 Aug 2012 00:09:19 +0300

> Maybe my bad English causes confusion. Sorry for that. The "simplified" here means we can remove the redundant functions of PANA and only keep the necessary part. That is exactly what we are trying…

We can certainly profile PANA to to not use those unnecessary parts (IP-reconfig bit… just a bit, don't use it).

> In addition, you remind me one thing. Karp WG is trying to use IKEv2 to provide key management for unicast routing protocols. If our WG decide to select a separated AKM
> solution. Do you think it is a good idea to borrow their work to secure PCP?
> 

Sure, it's a candidate. (Though, IMHO, IKEv2 is so IPsec-specific, using it for keying other protocols is a stretch).

Alper

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 2 Aug 2012 23:09:41 +0000

Hi -

These are couple of questions, I had raised in the meeting

1)If let's say the application is using both STUN and PCP. In STUN it can use long term credentials generate key (RFC 5389 section 15.4)
This brings in complexity of using two different mechanisms. Is it possible to make it more flexible ?
So that the application can either opt for long term credential approach similar to STUN or go with PANA ?

2)How will PCP authentication work b/w PCP proxy and PCP server ?

--Tiru.

> From: Alper Yegin [mailto:[email-masked]]
> Sent: Thursday, August 02, 2012 6:32 AM
> To: Zhangdacheng
> Cc: Margaret Wasserman; [email-masked]
> Subject: Re: [pcp] About selecting a key management for PCP
> 
> It's not simplified.... It's basically growing PANA (an EAPoUDP
> transport) within PCP. A redundant work that'd result in more
> complexity than keeping two simple protocols separate. This "oh I'll
> just carry EAP over my favorite protocol (e.g., DHCP!), and it'd be
> sooo simple" was tried before and failed miserably.  PCP and its key
> management are two separate issues that deserve two separate protocols
> (similar to IKE and IPsec being separate). I don't see any value in
> cobbling them up, which is more like a PPP-style approach -- all-in-
> one.
> 
> Alper
> 
> 
> 
> > We have a discussion about the selection of a key management
> mechanism for PCP, but there is not a conclusion yet. Basically, people
> focus on two solutions, using PANA or generating an in-band
> authenticaiton mchanism for PCP (actually a simplified PANA). Now,
> there is a new draft draft-ohba-pcp-pana-00, which tries to specify the
> first one. So, maybe it is the right time to raise this disucssion
> again and decide the key management solution for PCP eventually.
> >
> > Cheers
> >
> > Dacheng