Subject: [pcp] Embedded or separate KMP for PCP

From: Alper Yegin <[email-masked]>
Date: Tue, 27 Mar 2012 15:03:47 +0300

I recommend separating the key management protocol (KMP) from PCP.
Bundling the two up is a recipe for unnecessary complexity and cost. (I already elaborated on that, I can further expand if necessary).
I don't see the benefit. 

So, I recommend draft-wasserman-pcp-authentication-02 is split into two drafts:

Draft I: Integrity Protection for PCP (defining Authentication Tag Option, etc.)
Draft II: EAP transport over PCP (defining EAP Payload Option)

I support Draft I.

Draft II requires more discussion. Defining PCP-based EAP lower layer is one approach, using PANA is another, there are other ways to get crypto keys in place, etc.

Alper

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 27 Mar 2012 14:23:57 +0200

Hi Alper,

> Bundling the two up is a recipe for unnecessary complexity and cost. (I already elaborated on that, I can further expand if necessary).

You and Sam seem to disagree about the relative merits of separate vs. in-line key management protocols -- you seem to favor a separate approach (like IKE/IPsec), while Sam favors an inline approach (like TLS).  Hopefully some other people will join this discussion, so that we can reach some agreement about which is better for PCP. 

> Draft II: EAP transport over PCP (defining EAP Payload Option)

Given that the draft is 11 pages long, and that anything that referenced one of the documents would need to reference both of them, splitting the draft is not appealing to me.  If there is WG consensus to split the document, we will, but we do not need to have two separate drafts to discuss the options we have been discussing...  What benefit do you think this division will have for PCP implementers?

Margaret

---

From: Alper Yegin <[email-masked]>
Date: Tue, 27 Mar 2012 17:24:11 +0300

Hi Margaret,

> You and Sam seem to disagree about the relative merits of separate vs. in-line key management protocols -- you seem to favor a separate approach (like IKE/IPsec), while Sam favors an inline approach (like TLS).  

TLS is not the right analogy, on two very important fronts:
- There's standalone use of TLS as "a separate" KMP. RFC 5705 is driven by the fact that some other protocols need to use TLS as a "separate KMP". 
- TLS is basically "transport layer security", something that sits below the protocol we'd be trying to secure. We are not doing that.  

> Hopefully some other people will join this discussion, so that we can reach some agreement about which is better for PCP. 
> 

I agree.

> Given that the draft is 11 pages long, and that anything that referenced one of the documents would need to reference both of them, splitting the draft is not appealing to me.

Is this the guideline for hacking two protocols into one? If # pages < 15, keep putting more stuff in.

>  If there is WG consensus to split the document, we will, but we do not need to have two separate drafts to discuss the options we have been discussing...  What benefit do you think this division will have for PCP implementers?
> 

Using shared secrets to provide integrity protection for a protocol is one thing, (e.g., IPsec, SRTP)    
Defining a procedure to put those keys in place is another thing. (e.g., IKE, TLS with key exporter)
And they are distinct problems, which can use distinct and independent solutions.

There's no benefit in having hard-binding between the two. Sorry, reducing the number of references is not an important thing, really.
There are other ways to put the keys in place, such as using other IETF protocols (PANA), utilizing network access authentication, CGA, dynamic provisioning schemes, etc. There's no benefit in shutting these down. Is there?

Alper

---

From: Alper Yegin <[email-masked]>
Date: Tue, 27 Mar 2012 17:39:07 +0300

> We would be very happy to follow any decision of the WG. However, we need to be very carefully if we intend to select an existing kmp for pcp.

My proposal is to 
- treat KMP as a separate issue, 
- not bundle it up with the PCP integrity protection. 
- have a separate discussion on KMP,
- decide whether we allow multiple KMPs with the PCP integrity solution, or one (in which case, decide the "one").

> For instance, PANA does not support for MTU issue, if we intend to use it in pcp，Maybe  we need to discuss whether it needs to be extended. 
> 

PANA transports whatever EAP method sends (whether it's fragmented or not).
And whatever is provided by PANA gets fragmented at the IP layer, if and when needed.
So, what's really left as an issue?

Btw, now that you are proposing to define a "new EAP lower-layer (based on PCP)", can you please confirm if it satisfies the requirements stated in RFC 3748? 

Alper

> 
> Dacheng
> 
> 
> 在 2012-3-27，下午2:03， Alper Yegin 写道：
> 
>> 
>> _______________________________________________
>> pcp mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/pcp
>> 
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 27 Mar 2012 23:53:36 +0900

I have an architectural concern on defining application-specific EAP
transport (or what you call "in-line key management") because
it would advocate each application that requires keys to carry EAP by
using some portion of PANA specification in its own way, which can
easily lead to specification errors.  Even carrying the entire PANA
PDU as it is in application payload would require careful
considerations due to running a state machine of one protocol within
another protocol.  I really don't want to repeat a similar
time-consuming discussions that happened with EAP over DHCP proposal.

I believe the right way is to separate EAP transport from application
as much as possible, which makes application protocol designers to
focus on their own job (i.e., application protocol design).  And as I
already mentioned, I don't see any major implementation
cost/complexity issue on separating EAP transport and application.

Regards,
Yoshihiro Ohba