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

From: Sam Hartman <[email-masked]>
Date: Sun, 16 Sep 2012 12:38:05 -0400

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.

---

From: Alper Yegin <[email-masked]>
Date: Mon, 17 Sep 2012 12:24:32 +0300

> integrate them into their PCP servers and clients, and have

Good goal.

> EAP client, EAP server and RADIUS.

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

> exchanges will take multiple round trips,

And the direction of req/rsp is opposite.

> so multiple PCP messages may

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

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

> * Trigger authentications on the PAC when  PCP wants to talk to a server

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

>  consistent error reporting experience

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

> especially for things like denial of service.

Can you expand on this "DoS"?

> 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

So will any EAP lower layer.

> to need some cryptographic function (probably a hash-based MAC) for

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.

> and PCP. However PANA introduces significantly more duplication at the

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

> 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!" :-)

> would provide less value to our users because they could not re-use

Alper

> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Sam Hartman <[email-masked]>
Date: Mon, 17 Sep 2012 11:06:09 -0400

>>>>> "Alper" == Alper Yegin <[email-masked]> writes:
    >> 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:
    >> 

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

Margaret has gone into this detail somewhat.
The issue is that  you want a consistent experience  for the client.
So, you need to do things like map PANA failures because the server
doesn't support PANA into authentication not supported PCP errors.
You need to log PANA and PCP errors in the same place.
You need to provide consistent tools for looking at them.
These are implementation not protocol issues.

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

    Alper> Can you expand on this "DoS"?

Sure.
So, even in the demultiplexing case, we're coupling the state machines
together.
As an example we're creating a new PCP client state that is basically
waiting for PANA.
We need to do the security analysis for that.

One of the simpler issues is a question like can an malicious server
cause a PCP client to block indefinitely by swapping back and forth
between PCP and PANA.

--Sam

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 18 Sep 2012 07:46:47 +0900

Sam,

Thank you for your detailed implementation analysis.

As I already mentioned, I would expect open source implementors are
smart to accommodate your feedback, or they may even say more if you
are missing something.

I keep recommending to use something that is well defined and
interoperable instead of trying to re-invent the wheel, especially
where there is an agreement that all three approaches are similar in
functionality.  Given that all implementation points you made look
minor.  IMO, the major difference is whether a solution re-uses an
existing work or duplicates the work. Duplicating the existing work is
in general a bad idea.  It would be a nightmare if each protocol has
its own EAP over UDP variants and implementers need to implement each
of them, and PCP is not an exception.

Regards,
Yoshihiro Ohba

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Tue, 18 Sep 2012 14:38:44 +0900

Hi,

I'm an implementor of CPANA. I have two additions to your
analysis.

Firstly, you can add RADIUS support to CPANA by using FreeBSD's
libradius. For this purpose, we provide the option,
"--with-libradius", for the "configure" script of CPANA.

Secondly, you can also adapt third-party EAP implementations to
CPANA, though I've never tried.

Hope this helps.

Best regards,
Yasuyuki Tanaka

---

From: Alper Yegin <[email-masked]>
Date: Tue, 18 Sep 2012 10:41:28 +0300

> These are implementation not protocol issues.

Right, these are implementation considerations.
Logging with the proper info, whether it's coming from PCP or PANA is what we need.
So that tools can parse them properly.

> We need to do the security analysis for that.

That state is "retrieve security parameters" for PCP.
Those parameters could be:
- retrieved from a configuration file (static)
- retrieved from dynamic store (from last unexpired authentication)
- if both are empty, then PANA is triggered to generate fresh parameters

Given that PANA is already analyzed, not sure what other threats might be in here.
(on the other hand, if you want to re-invent PANA within PCP from scratch, you've got lot of security analysis to make. That's a lot of work.)

> cause a PCP client to block indefinitely by swapping back and forth

Not sure if I understand the scenario… Can you elaborate?

Alper

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 18 Sep 2012 11:28:31 +0200

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)

> your PCP product, this may not be a viable starting point.

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

> not include pre-built doxygen output.

That should not be a problem.

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

> commits dealing with fixing situations that work on a wired NIC but not

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

> 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

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.  

> client and server with authentication when discussing the PCP-specific

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

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.

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

> 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

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.

> things like event loops and execution models.

> OpenPANA brings along its
> 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. 

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

> and PCP. However PANA introduces significantly more duplication at the

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

> would provide less value to our users because they could not re-use

-------------------------------------------------------
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: [email-masked]
-------------------------------------------------------

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 18 Sep 2012 06:52:22 -0400

> So that tools can parse them properly.

Actually, I would argue that these are protocol design issues, not implementation issues.  Good protocol design makes it easy for implementation to get this sort of thing right.  Bad protocol design can make it much harder, or in some cases impossible, for implementations to provide a good experience to end-users.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 19 Sep 2012 06:11:05 -0400

Hi Alper,

> 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 "w…

You have mentioned this several times, but you haven't provided any specifics.  What do you think is missing from the PCP-specific approach, as document, that would need to be added to make it a "working" and "compliant" EAP lower layer?  Is there an RFC that specifies the requirements that the PCP-Specific approach is failing to meet? 

Margaret

---

From: Alper Yegin <[email-masked]>
Date: Thu, 20 Sep 2012 11:45:11 +0300

Hi Margaret,

> You have mentioned this several times, but you haven't provided any specifics.  What do you think is missing from the PCP-specific approach, as document, that would need to be added to make it a "w…

The major missing piece is the support for EAP re-authentication. It's totally omitted.

Security considerations section is too light on content. Please see PANA's. We need to see a thorough analysis to conclude that the design is complete. For example, there's a mention of DoS resilience, but it's not sufficient. Please refer back to PANA to see how DoS resilience is achieved with EAP lower-layer.

Also, I don't see the message validity checks (again, see PANA). It's not possible to get a standard state machine w/o that (either in a dedicated section like in RFC 5191, or captured in a distributed way in the document).

Alper

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 20 Sep 2012 06:31:27 -0400

Hi Alper,

> The major missing piece is the support for EAP re-authentication. It's totally omitted.

See my other message about that.
> Also, I don't see the message validity checks (again, see PANA). It's not possible to get a standard state machine w/o that (either in a dedicated section like in RFC 5191, or captured in a distrib…

Thanks for this feedback.  I will take it into account, as appropriate, depending on how we decide to go forward tomorrow.

Margaret