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

Hi Sam,

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

Please see below.

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

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

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

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

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

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

You'd need to trigger re-auth. 

> We do
> not need support for IP address reconfiguration on successful
> authentication.

That's right. That part is extra.

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

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.

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

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

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

> 
> PANA assumes an architecture where a DHCP option provides the address of
> 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
> 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.
> 

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. 

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

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

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

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

Sure. This is usual a system development issue.

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

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

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

Sam, PANA is also using EAP. 

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

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.

> Finally, I don't think PANA implementations are widely available on
> most PCP targets today.

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

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

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.

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

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