Re: [pcp] Implementation Analysis: strong preference for PCP-specific approach

On Sep 16, 2012, at 7:38 PM, Sam Hartman wrote:

> So, I've done a few hours of implementation analysis and come to a
> conclusion.  Before I get to my conclusion, and my analysis, I'd like to
> discuss how I think this fits into the WG process.
> 
> The IETF doesn't really deal with implementation issues except in so far
> as they impact the standardization process.  I claim it's entirely
> reasonable for WG participants to factor in the question of which of the
> three approaches we're considering would be easiest to implement  into
> their decision of which approach to standardize. "Hey, it's easy to
> build x and not y," seems like a fine reason within the IETF process to
> prefer x and not y.
> That's what I'm doing here; I'm presenting my opinion on what's easy to
> build as a rationale for my opinion  on which option to standardize.
> I hope to convince you to agree with me about  which option to
> standardize.
> 
> However, we're not coming to consensus on which option  is easiest to
> build; the IETF doesn't reach consensus on implementation issues.
> I'm presenting my reasoning only so you can judge how valuable my
> opinion is. If I got something factually wrong--for example I missed a
> capability of an implementation--point it out. If you disagree with the
> tradeoffs that are important to me, it's probably better for you to post
> your own analysis based on your own tradeoffs than to try and convince
> me my tradeoffs are "wrong."
> My goal:
> I think that we have a lot of open-source security tools around. I want
> it to be easy for people to add authentication to PCP
> implementations. For that reason I would strongly prefer us to
> standardize a solution where people can pick up existing libraries,
> integrate them into their PCP servers and clients, and have
> authentication.
> 

Good goal.

> 
> My conclusion:
> Based on the existing open-source tools and libraries, I think it would
> be much cheaper and simpler for me to integrate a PCP-specific
> authentication approach into PCP than to integrate either PANA
> encapsulation or demultiplexing.
> Even if you have proprietary PANA implementations, some of the issues I
> identify below may apply.
> 
> That said, I agree with Margaret that all the approaches are technically
> viable and with enough work any of the three approaches will work. In
> terms of what they provide, they are very similar. Since they are
> similar, simplicity and cost are important factors in my decision
> criteria.
> 
> Even if you skip the detailed comparison below, I recommend reading the
> "General Notes" section at the end.
> 
> All three approaches have some components in common.  The PCP client
> will need an EAP supplicant library; for the PCP-specific approach this
> will be used directly. For the PANA approaches, the EAP supplicant will
> be used indirectly via the PAC. the PCP server will need a RADIUS
> library, an EAP server library or both. The RADIUS library is valuable
> if you're integrating into a corporate or ISP infrastructure. the EAP
> server is valuable if you're trying to provide authentication for a
> simple home gateway that integrates into nothing else. Again, for a
> PCP-specific approach, these libraries will be used directly; for a PANA
> approach, they will be used by the PAA.  One factor to consider in
> evaluating these components is whether the library in question provides
> access to the EAP methods that your customers need. I'd want a library
> that exposed a couple of tunnel methods from the set (EAP-FAST,
> EAP-TTLS, EAP-PEAP, EAP-LEAP) and a couple of inner methods from the set
> (EAP-MSCHAPv2, EAP-PAP, EAP-PSK, EAP-GPSK) and possibly EAP-TLS.  One
> EAP implementation we'll run into a couple of times below is the one
> from hostap/wpa_supplicant (http://w1.fi/).  Your product may already be
> using this or parts of it for 802.11i.  It's a actively developed very
> cross-platform library. You can use it as anything from an EAP library
> directly all the way up through an 802.11i implementation. It includes
> EAP client, EAP server and RADIUS.
> BSD licensed.

There's a distinction between "analyzing a specific implementation of Foo" vs "analyzing implementation of Foo".
You better point out which one this analysis is about.
And it has to be an apple-to-apple comparison (not specific implementations of one [PANA] vs conceptual implementations of the other [EAP-over-UDP/PCP])  

Use of EAP methods is not impacted by which protocol is the EAP lower layer (PANA, PPP, IKEv2, 802.1X). 

> 
>                         PCP-Specific Approach
> 
> I've managed a project where we added EAP authentication  to an
> application (well really set of applications) using a protocol specific
> to our application. We were implementing draft-ietf-abfab-gss-eap. In
> effect we were build an application security mechanism based on top of
> raw EAP. As such we got experience with an EAP-specific approach ported
> to Linux, Windows  and Mac. The Windows port is heavily integrated into
> the operating system, including providing a security support provider
> integrated into the local security authority.
> We have not yet ported this to mobile or embedded environments.
> We used the wpa_supplicant EAP library.
> Because of requirements that applied to our project but not PCP, we
> ended up funding development of a new RADIUS library (we wanted support
> for RADIUS over TLS which is still in development).  For PCP, we could
> have used the RADIUS support in the wpa_supplicant stack, or a number of
> existing RADIUS libraries.
> 
> 
> See the eapGSSSMInitAuthenticate function in
> http://www.project-moonshot.org/gitweb?p=mech_eap.git;a=blob;f=mech_eap/init_sec_context.c;h=9da9f4f7cffd68c4c77a8efdbecaa1e87b0865f5;hb=65b06d7e720738acf873c20933e36fae0fe857fd
> for how we integrate EAP into the client. See
> eapGSSSMAcceptAuthenticate function in
> http://www.project-moonshot.org/gitweb?p=mech_eap.git;a=blob;f=mech_eap/accept_sec_context.c;h=aeba1b4d8e5b4b50128c4c04470f9c778117dbda;hb=65b06d7e720738acf873c20933e36fae0fe857fd
> for how we integrate RADIUS into the server.
> 
> 
> The biggest challenges on the EAP side were adding configuration to the
> applications to choose the right username, password and where
> appropriate TLS certificate for the server were connecting to.
> There were also some minor build challenges for wpa_supplicant. The
> library code  is well isolated, but their build system doesn't do a
> great job of building shared libraries/dlls components for other
> projects to re-use.
> A wide selection of EAP methods are available.
> 
> On the RADIUS side, we actually spent a lot of time, almost all of that
> was because of special things our project is doing with RADIUS. There
> was an early prototype that had an integrated EAP server and a bit later
> that used a stock RADIUS library.
> Both of those ended up being fairly simple.
> 
> We did get the library re-use we expected. As I recall, We needed to make no changes
> to wpa_supplicant code to use it. We did change their build system a
> bit. As I recall, we submitted a couple of small bug fixes to the stock
> RADIUS library when we used that, but those bug fixes were quickly
> accepted upstream.
> 
> We were lucky that the state machine we were dealing with ended up
> supporting multiple round trips already. One potential complexity in
> integrating PCP-specific authentication into a PCP server  is that EAP
> exchanges will take multiple round trips,

And the direction of req/rsp is opposite.

> so multiple PCP messages may
> be sent in response to an application requesting a mapping if an
> authentication session is not set up. In many cases, existing
> retransmission strategies will already include this complexity in the
> client state machine.
> On the server, if RADIUS is used, then responding to an incoming PCP
> authentication request will require waiting for the RADIUS response;
> this may complicate the server state machine.
> 

Right. Port-sharing does not have this problem as EAP/PANA is run independently.
PANA tunneling and EAP-over-PCP has this issue.

>                                 CPANA
> 
> See http://sf.net/projects/cpana
> 
> At first glance, CPANA looks promising. It's designed as a library for
> others to integrate PANA into their environments.
> CPANA is distributed under the BSD license.
> 
> Unfortunately, I quickly decided  that CPANA was not a credible start
> point in my opinion. The project has received 11 code commits over its
> entire lifetime; I think 1 or 2 commits this year.
> Despite claims that "docs are coming soon," in 2010, I was able to find
> no documentation. There doesn't seem to be good separation of what is a
> public interface from what is an internal interface; cpana.h includes
> all the internal header files.
> The example applications don't separate example-specific functionality
> like reading config files well from using the library, so I wasn't able
> to get a feel for what it would be like to use the library in a
> non-sample application.
> On a positive note, there did seem to be an abstraction around where
> responses went; it might be easier-than-expected to use CPANA in an
> encapsulation or demultiplexing approach.
> 
> There's one additional huge problem with CPANA. It includes its own
> rather limited EAP library which does not appear to support any of the
> tunnel methods. On the server there appears to be no RADIUS support.
> If I were writing a PANA library I planned to maintain for years, I'd
> seriously evaluate taking chunks of code from CPANA.
> If CPANA gets significant new development effort it may turn into
> something interesting. I like the goal of separating library from application.
> 
>                                OpenPANA
> 
> Took a look at http://sf.net/projects/openpana.
> OpenPANA is under significantly more active development than CPANA.
> One initial concern is the GPL3 license. Depending on the license of
> your PCP product, this may not be a viable starting point.
> 
> OpenPANA used wpa_supplicant as an EAP stack; this is good. The code has
> fairly reasonable doxygen markup. The website and source distribution do
> not include pre-built doxygen output.
> 
> OpenPANA's description claims that it includes libraries and
> applications. This is true, but the libraries are at the level of
> parsing PANA messages and utilitiy functions. Much of the guts of the
> PANA implementation is built into the applications.
> The applications are specific to network access; as an example there are
> commits dealing with fixing situations that work on a wired NIC but not
> on a laptop.
> 
> OpenPANA assumes a threaded execution model. If your PCP product is
> asynchronous event based, this would be a significant integration
> concern. OpenPANA is an application; it uses malloc and other C library
> memory management functions directly. Turning that into a library can be
> painful for some environments.
> 
> Regardless of  wich PANA approach we pick, you'd need to do some common
> work to OpenPANA to make it useful for PCP. You would need to remove the
> network access code and replace the configuration parsing.
> 

Instead of removing the code, we just not use that code-path when PANA is executing for PCP.

> For the encapsulation approach, you'd need to make fairly major
> changes. You'd want OpenPANA to run as a library. Also, it really wants
> to handle sending the messages itself. Structures have a sockaddr_in (or
> sockaddr_in6) to which messages are sent. You would instead need to
> restructure all that as callbacks or similar. You'd also need to
> consider the comments I made about aligning the PCP state machines on
> client and server with authentication when discussing the PCP-specific
> approach.
> 
> Parts of the demultiplexing approach look simpler. You could run a PAA
> and PAC as separate processes. If the PCP server received an
> authentication request it could forward it to the PAA over a local
> socket. You'd need to make a slight change so that the return address
> could be preserved. In this mode, the PCP server would not need to
> change its state machine to wait for authentication. 
> Except then it gets complicated, because you need coordination between
> PCP and the PAC/PAA.  You need to design an implementation-specific
> protocol to:
> 
> * Trigger authentications on the PAC when  PCP wants to talk to a server
> 

Yes, we'd need to add a new trigger (PCP trigger).

> * update the PCP client on authentication state including session ID,key
>  ID, and negotiated algorithms
> 
> * Provide error feedback from the PAC to PCP server so the user gets a
>  consistent error reporting experience
> 

We do not send error codes in PANA. Not sure which error reporting you are referring to.

> * Update the PCP server on new authentication sessions at the PAA
>  including IDs, keys and algorithm identifiers
> 
> If you do all that work you're going to end up with a fork of OpenPANA,
> not just get a library you can use and potentially refresh for new
> products/product releases.  Security analysis will be different
> especially for things like denial of service.

Can you expand on this "DoS"?

> 
> I'm quite certain making the necessary changes to OpenPANA would be more
> complex and likely to be more expensive than integrating a PCP-specific
> approach.
> 
>                             General notes
> 
> When you glue technologies together, you add complexity. Some of that
> complexity is inherent--for example adding multi-round-trip
> authentication to PCP simply will add complexity.
> Some of that complexity is in the implementation domain.
> 
> There are EAP and RADIUS libraries out there that have been designed to
> work well with applications. They tend to interface to the existing
> event loops, tend to allow the application to supply memory allocators,
> that sort of thing. They tend to support the application providing
> configuration information.
> Even so, the EAP library is going to bring along its own session
> management and message reassembly.
> All the options we're discussing involve that complexity.
> 
> Pana is yet another framework on top of EAP.
> The PANA specifications are scoped for network access; however we're not
> directly doing network access. The changes to PANA specs between network
> access and application authentication are not very large. However we
> still need to consider the benefits especially at an implementation
> layer.
> 
> The PANA implementations I've looked at aren't all that thin. They
> include session layers on top of the EAP session layer.

Yep, they are implementing "EAP lower layers". "EAP-over-UDP/PCP" is an EAP lower-layer and it'll have the same thing (once people realize it's more than defining a EAP container to qualify as a "working" and "compliant" EAP lower layer).

> They are not as
> mature as the EAP implementations; they will place more constraints on
> things like event loops and execution models. OpenPANA brings along its
> own alarm linked lists and retransmission infrastructure on top of what
> exists in the EAP library. It brings along its own PRF+, AES and CMAC
> implementations.

So will any EAP lower layer.

> 
> Yet, it's easy to see a PCP server or client duplicating a lot of this
> too. PCP's going to need a session and retransmission layer; it's going
> to need some cryptographic function (probably a hash-based MAC) for
> integrity.

Yes, for its own "PCP" needs.

> PCP already has its own approach to liveness duplicating what PANA does.
> 

OK, PCP can rely on PANA ping instead then.

> Yes, if you re-use an existing EAP library and are not making
> significant customizations then there will be duplication between EAP
> and PCP. However PANA introduces significantly more duplication at the
> implementation layer.
> 

??
PRF, AES, CMAC…. are used all over the stack by many protocols for their own needs. Use libraries for them. But seeing protocols as redundant because they are using these common bits does not make sense to me.

> My opinion is that when I consider the extra effort to use PANA and the
> extra code it brings along, I don't see what value it brings.
> 

The main flaw with this "analysis" is you or anyone else has not seen the "EAP-over-UDP/PCP" implementation.
And in fact, we have not even seen the "complete, working, and compliant" EAP-over-UDP/PCP "protocol". 
So, something that's not designed/implemented is "always simpler!" :-)

> 
> You could argue we could save even more by dropping EAP completely and
> doing something so PCP-specific that it didn't re-use a security
> framework at all. that would be a hard sell for the security area and
> would provide less value to our users because they could not re-use
> existing infrastructure.

Alper

> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp