Subject: [pcp] wasserman-pcp-authentication: pana alternative

From: Sam Hartman <[email-masked]>
Date: Sun, 25 Mar 2012 16:52:55 -0400

Hi.
It's taken me a while to investigate the alternative of  using Pana for
PCP authentication that was suggested back in November. My apologies for
the delay; I needed to swap the PANA spec back in.

In general, I have found that including key management in-band with a
protocol yields simpler implementation and deployment experience than
out-of-band key management. Compare your experience with something
in-band like a TLS web server with something out-of-band like IPsec to
get a feel for the general issue. Most people find that web servers are
easier to deploy and configure than IPsec solutions.
I'm not alone in the security area in holding this opinion. Several
security area experts argued that KARP (the effort to add authentication
and key management to routing protocols) would be simpler if it used an
in-band approach. There, the KARP working group is having to do
out-of-band key management because of domain-specific
constraints. Describing the abstract interface between the key
management part and the routing protocol part is proving difficult to
get consensus on. I suspect that would be simpler (but not simple) in
PCP.  So, while I believe that out-of-band key management can work for
PCP, I think the implementation and standardization effort will be
simpler if the working group adopts  an in-band approach such as an
EAP-based solution rather than an out-of-band approach such as a PANA
solution.

I'd like to explore some of the differences. I'll start by examining
issues apparent  at the protocol level.

PCP does not need all of the PANA messages. We do not need a
separate notification protocol for liveness of sessions. We can use PCP
facilities for that. We do not need a re-authentication protocol. We do
not need support for IP address reconfiguration on successful
authentication.
so, an EAP-based solution can directly avoid some of the parts of a PANA
solution; this may result in reduced code size and complexity.

PANA would need to change in order to support use for applications other
than network access.
In PANA today, there is not a clear mechanism for indicating what
application a PAC is authenticating to. A PAA needs to know this for a
number of reasons. For example in EAP channel binding
(draft-ietf-emu-chbind), a AAA client such as a PAA is expected to
include an eap-lower-layer AAA attribute so than an EAP server can
validate channel bindings from the client against channel bindings from
a server. In PANA today, the PAA has no way to tell whether the client
is authenticating to PANA because it wants network access or because it
wants to access PCP. I think PCP is close enough to network access to
fall under RFC 3748's current applicability statement, but I think that
PCP counts as a different EAP lower layer than PANA for network access.
Similarly, some clients may be authorized to access  a network but not a
PCP server or a PCP server but not a network. PANA needs to gain a
mechanism to distinguish this. PANA implementations would need to gain
support for that.
Handling this in an EAP-based solution is quite easy.

PANA assumes an architecture where a DHCP option provides the address of
the PAA to the PAC (RFC 5192). We have two choices. We can use this
model. That means that the PAA MAY not be the same device as the PCP
server. In this model we'd need to standardize a protocol for carrying
the security association from the PAA to any PCP server served by that
PAA. Alternatively we could choose to require that the PAA be
co-resident with the PCP server. That is yet another variation from how
PANA normally works  that increases implementation cost and
complexity. In an in-band solution it's natural to bind the
authentication to a given PCP server.

There are several aspects of RFC 5191 that assume PANA is being used to
achieve IP connectivity. The most obvious is one I've already pointed
out: the IP address reconfiguration bit. These aspects of the
specification are likely to influence implementation choices; the
implementations of PANA are likely to be optimized for this use
case. This means they are likely to be more expensive to retool to fit
PCP's use case. (This may be less of an issue if PANA is not generally
available on a given platform and you start from scratch rather than
including a existing version.) An EAP-based solution would be customized
to PCP.

However, I think the most significant issues are not obvious from the
specification. PANA is likely similar effort to an EAP-based  if PANA and
the PCP server are part of the same monolithic code base that can share
variables and data and can be refactored together. However, if that's
not true, it gets more complex to implement. For example if your
platform has separate processes and PANA and PCP run in different
processes, then you'll have to define a communication mechanism between
PANA and PCP. If your platform uses PANA for more than just PCP (which
presumably is a benefit of using PANA--it can be applied to more than
one application), you will need to manage SAs for PCP distinct from SAs
for other uses. If your PANA and PCP code come from different sources,
then you need to specify the interfaces used to communicate between PANA
and PCP in whatever manner your platform uses for this sort of internal
interface development. For some platforms that's a fairly big deal. If
you are hoping to take advantage of PANA as a platform service exposed
to multiple applications, then you'll have to version these interfaces
and support backward compatibility or a forward evolution path. We
believe that adds significant complexity. 

We believe that an EAP-based solution  provides vendors a much better opportunity
to trade off code sharing vs interface cost and be more likely to be
near the lower cost/complexity side of the tradeoffs. For example, an
embedded device could share the same EAP library both for network access
and PCP. Such a device is likely to have a monolithic code base and is
likely to be able to avoid most needs to specify platform-specific
interfaces other than the API of the EAP library. Alternatively a server
for a non-resource-constrained PCP system can pick the most convenient
open-source EAP passthrough library. They are more concerned with
avoiding implementation cost than code size. If PANA had been used, then
the fact that all PAA traffic on the box uses the same port would
significantly complicate the server implementation.

Finally, I don't think PANA implementations are widely available on
most PCP targets today. There are some networking technologies that are
looking at/have adopted PANA, so availability of PANA implementations on
platforms is likely to rise. However, EAP is available on all these
platforms today.

In conclusion, we believe an EAP-based solution  is a better fit for PCP's
requirements than a PANA based solution. However, if the WG chooses to
use PANA, we'd be happy to edit our draft to reflect that consensus.

Sam Hartman
Principal Consultant
Painless Security, LLC

---

From: Alper Yegin <[email-masked]>
Date: Mon, 26 Mar 2012 12:33:24 +0300

Hi Sam,

Thanks for the detailed analysis and response. This is a good discussion.

Please see below.

> easier to deploy and configure than IPsec solutions.

I'm under the impression that this has more to do with the nature of IPsec vs TLS, as opposed to the key management used for each.  Would IPsec have been easier to use than TLS if IKE were integrated into it?

Key management and subject protocols are two distinct things. They have different state machines, and messaging. Bundling the two up would only increase cost, and complexity. Basically, what you are suggesting boils down to embedding EAP transport into any protocol that needs "crypto keys", and obviously this is a lot of standardization work, and coding work eventually. It's much better to utilize modularity for such distinct protocols than to monolithically integrate them one at a time. Modularity also yields flexibility, as there are many different ways of getting keys in place. 

> in-band approach.

EAP has a very peculiar state machine. Trying to wedge it in an another protocol is a challenge. DHC WG tried that, and after so many years of effort it failed. DHC and EAP has incompatible state machines. 

> There, the KARP working group is having to do
> get consensus on.

Isn't that an implementation issue: How one gets keys from one piece (a config file, or dynamic state produced by a protocol) to another? 

> I suspect that would be simpler (but not simple) in

This is not "EAP vs PANA", btw. As you know, PANA is an "UDP-based EAP lower layer". Your proposal is "PCP-based EAP lower-layer". 

> facilities for that. We do not need a re-authentication protocol.

You'd need to trigger re-auth. 

> We do

That's right. That part is extra.

> solution; this may result in reduced code size and complexity.

I disagree. If we go with "EAP over any protocol that needs crypto keys", we'll end up O(N) standardization work and O(N) implementation.

> wants to access PCP.

Default of PANA is for "network access".
By simple addition of a AVP, we can indicate "this PANA session is for PCP". This is trivial.

> I think PCP is close enough to network access to

It'd be more accurate to call that "EAP over PCP"-based solution if we are contrasting it with PANA (which is EAP over UDP).

> the PAA to the PAC (RFC 5192).

This is one way. It's not mandatory to use. If there's another way to discover PAA, that can be used too. However PCP server is discovered can be used here, and we can declare PCP server and PAA are co-located. I think you also make the equivalent assumption in your EAP/PCP design.

> We have two choices. We can use this

I think EAP authenticator in your design is collocated with PCP server. Right? If so, PAA is also collocated with the PCP server.
Otherwise we both have the same issue of dealing with the split. 

> PCP's use case.

You just don't use IP reconfig, that's it. We do not use every bells and whistles of each protocol in each deployment.

> (This may be less of an issue if PANA is not generally
> specification. PANA is likely similar effort to an EAP-based

Except that (*),

- PANA is already a RFC standard,
- It's adopted in the industry (Zigbee Alliance),
- There are two open source implementations, 
- And multiple commercial ones already passed interop events

>  if PANA and
> for other uses.

The AVP I mentioned above splits the space into multiple applications, and SAs are managed separately.

> If your PANA and PCP code come from different sources,
> interface development.

Sure. This is usual a system development issue.

> For some platforms that's a fairly big deal. If

It's just addition of one AVP. I wonder where the  complexity comes from? 

> and PCP.

Sam, PANA is also using EAP. 

> Such a device is likely to have a monolithic code base and is

I don't understand that. 
Your approach yields O(N) implementation cost and code size as you are advocating turning every protocol that needs crypto keys to embed EAP (i.e., becoming an EAP lower layer in RFC 3748 terms). This cannot be efficient.

> most PCP targets today.

But it's well-ahead of EAP over PCP implementation :-) Please see above (*)

> There are some networking technologies that are

EAP is there. But what we are really talking about is the "EAP lower layer", whether it'd be PANA or your EAP-over-PCP design.
Having EAP and PCP on one platform does not give you EAP-over-PCP for free.

> use PANA, we'd be happy to edit our draft to reflect that consensus.

I think at the minimum we should split key management from PCP security, as two I-Ds.
Then we can continue discussing whether one keys the later using PANA, your EAP-over-PCP, or some other mechanisms.
Bundling up is extremely constraining, and overly-complicating (marriage of state machines), and costly.

Reagrds,

Alper

> 
> Sam Hartman
> Principal Consultant
> Painless Security, LLC
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Alper Yegin <[email-masked]>
Date: Mon, 26 Mar 2012 16:58:13 +0300

>> out-of-band key management.

Interestingly, even with the TLS, people did need separate key management protocol, and that led to RFC 5705.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 26 Mar 2012 10:00:39 -0400

Hi, Alper.
I agree this is an excellent discussion.

First, you're absolutely right that the question is whether EAP should
be directly integrated into PCP or whether PANA should be used to carry
the EAP traffic.  If I implied PANA does not use EAP, that was
unintentional.  These solutions are similar in many ways.

I think that we value different tradeoffs and make different complexity
assumptions.

I think that integrating a security mechanism like EAP into a protocol
is not much more expensive than integrating something like PANA into a
protocol.
You believe that the complexity of matching state machines and  doing
this standardization work is fairly expensive.

I believe that working through the details of how to adapt PANA to a use
besides network access is complex.

I am more concerned about the implementation costs within a
platform--the issues that you described as system development.

Now, I think it's time for the WG members to evaluate these approaches,
ask any questions they have and make a decision about these tradeoffs
for themselves.

---

From: Alper Yegin <[email-masked]>
Date: Mon, 26 Mar 2012 18:51:13 +0300

Hi Sam,

> is not much more expensive than integrating something like PANA into a

There's a confusion here too. There's no "integrating PANA into a protocol" being discussed here either. 
It's about "using" PANA (+ defining one new AVP), as opposed to defining a whole new EAP lower-layer based on PCP (your proposal).

> besides network access is complex.

I have yet to understand how that's the case. Can you elaborate?

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 27 Mar 2012 03:34:53 +0900

Sam,

Besides what was already responded by Alper, I have one comment.

I am not sure what platform you have in mind, but we implemented PANA
on multiple microprocessor platforms (See for example
http://www.iab.org/wp-content/IAB-uploads/2011/03/Ohba.pdf) in
addition to x86 platforms with Windows and Linux OSes, with exporting
keys to other protocols.  There has been no major complexity/cost
issue found for such PANA implementations.  I would suggest trying out
existing open-source PANA implementations such as cpana and openpana
if you have not tried one yet.

Regards,
Yoshihiro Ohba

---

From: Sam Hartman <[email-masked]>
Date: Tue, 27 Mar 2012 04:44:51 -0400

>>>>> "Yoshihiro" == Yoshihiro Ohba <[email-masked]> writes:

    Yoshihiro> Sam, Besides what was already responded by Alper, I have
    Yoshihiro> one comment.

    Yoshihiro> I am not sure what platform you have in mind, but we
    Yoshihiro> implemented PANA on multiple microprocessor platforms
    Yoshihiro> (See for example
    Yoshihiro> http://www.iab.org/wp-content/IAB-uploads/2011/03/Ohba.pdf)
    Yoshihiro> in addition to x86 platforms with Windows and Linux OSes,
    Yoshihiro> with exporting keys to other protocols.  

Hi. I think of a platform as something like the official Windows Mobile
release or the official Android release or something like that.  There's
a lot of effort in taking an implementation that runs on a platform and
integrating it into that platform as the distributor/author of that
platform in a way that you can support it going forward and that it's
available as a platform service.

In terms of things that are easily observed externally look at the
effort a Linux distribution like Fedeora, Debian or Ubuntu spends
integrating software into their platforms.

--Sam