Re: [pcp] Comparison of PCP authentication

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Alper Yegin
> Sent: Thursday, August 02, 2012 2:31 PM
> To: [e-mail]
> Subject: [pcp] Comparison of PCP authentication
> 
> http://www.ietf.org/proceedings/84/slides/slides-84-pcp-10.pdf
> 
> Ah, isn't it odd that this beauty contest is run by one of the
> contestants? This material should have been prepared and presented by a
> neutral party.
> 
> One important question: With this proposal, are the authors advocating
> each protocol should come with their own in-band key management, more
> specifically embedding an EAP transport?
> 
> 
> > what's the big deal of using the same port vs different port? Is
> jamming all in the same port is a benefit?
> 
> > "TLS is in-band"
> 
> - 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 one would be trying to secure. We are not doing
> that.

To throw another TLS thing into the mix:

DTLS-SRTP [RFC5764] uses the (D)TLS handshake to encrypt SRTP and is
pretty well aligned with what we want for PCP -- we want a key
exchange and then run the PCP protocol natively.  DTLS-SRTP has a 
normal DTLS handshake, followed by SRTP packets that appear normal 
on the wire (that is, the packets are RFC3711 packets which have
their RTP headers in the clear).  It does this over the same socket,
because the first byte indicates if the packet is DTLS, SRTP, or
STUN (ICE), http://tools.ietf.org/html/rfc5764#section-5.1.2.

At the meeting, I suggested we consider if PANA and PCP could
be similarly demux'd.  Stuart suggested using some sort of GRE-
like header if they cannot be demux'd.  Either approach would 
eliminate one of the objections of PANA, specifically its use 
of a separate port.

-d



> > are the EAP and PCP state machines compatible? If marrying two
> protocols, one needs to pay attention to this. This was one of the
> reasons why EAPoDHCP did not work.
> 
> > Does the EAP-over-PCP satisfy the "EAP lower layer requirements" as
> stated in RFC 3848? I had asked this question but don't remember seeing
> any response.
> 
> > "Possible in-band optimization". Is this documented anywhere? It's
> not easy to understand how it works by looking at this slide.
> 
> > PANA RFC 5191 was published in 2008, not 2011. It's adopted by Zigbee
> IP, ETSI TISPAN, and also ETSI M2M. Aside from two open-source
> implementations, multiple commercial implementations have successfully
> passed interop events in Zigbee Alliance.
> 
> >
> 
> *	Need to specify the portions of PANA that don't need to be
> implemented
> 
> 	in a PCP PANA Client and Server (such as IP Address
> reconfiguration)
> 
> 
> 	>> this is just a single bit flag. We don't use it, and that's
> all we need to do about it.
> *	Need to specify/describe interface between PANA and PCP elements
> 
> 	>> this is an implementation issue, like how the other spec
> implementors would need to define the interface between the EAP and PCP
> for passing keys, etc.
> 
> *	Need to specify how the PANA client finds the correct PANA Server
> for PCP Authentication (may be passed from PCP client?)
> 
> 	>> PCP server the the PAA are the same node.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>