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

Hi Sam:

First of all, thank you very much for this analysis. OpenPANA team really appreciate it.

I would like to give my 0.02 cents about this discussion and then give specific comments related with OpenPANA.

Transporting EAP in any protocol to provide authentication and network access is a general idea which we have seen several times. Basically, this has meant to design a new EAP lower-layer for EAP (or to force a protocol for one purpose to be an EAP lower-layer). 

In any case, you need to start the process of designing this EAP lower-layer seeing what it is needed in terms of any EAP lower-layer requirements should be accomplished and its interactions with EAP state machine. This path was already covered with the design of PANA. 

Now it seems that PCP with a specific purpose wants to be adapted to be an EAP lower-layer. Then, presumably, people will have to cover a similar path as PANA did to cover all interactions with EAP sm, retransmissions, etc... (which basically have been the outcome of an IETF WG). So, my expectation of the final outcome in the PCP-Specific Approach is something which is, in essence, (let's say) 90% PANA-alike with small modifications for adapting it to the peculiarities in this scenario. In fact PCP-Specific Approach seems to inherit things that I have already seen in PANA (which seems a logic consequence of what I am saying)

Going this way is possible, but there is also another way: covering (let's say) 10% of the path to adapt PANA to the particularities of the scenario because 90% of the work of designing a EAP lower-layer is already designed in PANA. 

So, at first sight, and from my experience on designing a new EAP lower-layer (and the great effort of doing it) I would take the PANA option since, simply, most of the work is already done. Obviously, this is just my opinion if I would have to do the job. Having said that, I understand that WG should determine what path to cover.

Regarding OpenPANA, I have a few comments once I have been commenting this with OpenPANA developers (I am simply the supervisor of OpenPANA project), and in general we do not see major problems to carry out the different changes that you propose. In fact, we think that we would not base this difficult decision in the existing open source implementations. After all, they are not final products (at least in the OpenPANA case)

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

This is easy to fix. No problem to change this.

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

That should not be a problem.

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

That is correct. However, this should not represent a major issue. In fact, we already have some experience on the scheme you propose. An example is our IKEv2 implementation (http://openikev2.sourceforge.net)

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

It has already tested in wireless interfaces. So it should not be a problem either.

> 
> OpenPANA assumes a threaded execution model. If your PCP product is
> asynchronous event based, this would be a significant integration
> concern.

Our very preliminary versions was based in a non-threaded model. In fact, we have implemented a PANA client for Contiki SO in smart objects (PANATIKI) as part of OpenPANA project, which uses a model based on events. 

Note that even when we are using threads, we have been able to run OpenPANA (PAA) in Linksys Access Router with OpenWrt. 

In any case, as I mentioned, this is not a final product. This is just a modest open source implementation :).

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

Replacing that should not be a major problem. In fact, internally, we have already used OpenPANA to bootstrap other security associations not related with network access. It is fairly easy.  

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

This is correct, but the reason is simple: PANA was originally transported in UDP. So following the standard, this is the way to carry PANA. If a new transport for PANA is designed/standardized this should be reflected in the implementation. Obviously. But I think that if we were able to develop OpenPANA, we could achieve also this.

> 
> Parts of the demultiplexing approach look simpler.

Personally, I like this approach more.

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

Yes, you need design an interface which coordinates the PCP SA with PANA authentication. That is right. In fact, this interface is already considered in PANA State machine RFC (http://tools.ietf.org/html/rfc5609). In fact, we have used rfc5609 as a reference for developing OpenPANA.

In any case, as I mentioned we have already played with other types of SAs not related with network access control.

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

This interface with this functionality you describe was more or less defined some time ago (e.g. variable AUTH_USER to trigger the PaC, authorize() function to enforce a state, etc...) . Most probably it may be improved but somehow it is already there. Moreover it is worth noting section 9.1 in RFC5609 where some comments are made about this interface

> 
> If you do all that work you're going to end up with a fork of OpenPANA,

It would really be nice to have that fork :)...

> not just get a library you can use and potentially refresh for new
> products/product releases.

...but having a library is also fine. I guess it is a matter of need. If people need it, it would be a matter of doing it :). It should not be a major issue. As I say we already have some experience on having this kind of libraries.

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

I cannot tell about how a PCP-specific approach implementation will be. However, as I commented, under design point of view I envisage a long and hard path on having a new PCP EAP lower-layer. By the simple fact that it is not an easy task to design a correct EAP lower-layer following all the requirements. 

Regarding OpenPANA implementation, from the discussions I have maintained with the main developers, I can conclude that it requires work (as everything), yes,  but "complex and expensive" would not be the terms we would use.  

More comments below.

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

Yes. The reason is that PANA has their own retransmission mechanism different than EAP. 

> It brings along its own PRF+, AES and CMAC
> implementations.

AES CMAC were added because OpenPANA includes support for a PaC for Contiki (PANATIKI, included in OpenPANA project). This kind of cryptography was required in the PAA to support certain particularities when PANATIKI PaC was installed in smart objects. This is a long story but it is not related with this discussion :). In fact, PANA RFC does not mention anything about AES or CMAC. 

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

As I commented at the beginning of this e-mail most probably, most of the same road covered with PANA will be again covered when designing a PCP-native approach. 

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

Not sure if I understand where the "more" duplication is.
> 
> 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.

To me, it brings the value of saving the amount of cycles that will be required to design a new EAP lower-layer. Apart from the fact that we would not expect major problems on extending OpenPANA (or any existing PANA implementation) following your recommendations. 

Best regards and many thanks for your expert insight, it can really help us to improve OpenPANA in the future!.

> 
> 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.
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
-------------------------------------------------------