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

[Sam Hartman <[e-mail]>]

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.


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.

                         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, 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.

                                 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.

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

* 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

* 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.

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. 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.

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.
PCP already has its own approach to liveness duplicating what PANA does.

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.

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.


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.