Subject: [Pana] RE: [secdir] Last Call: 'PANA Framework' to Informational RFC

From: "Alper Yegin" <[email-masked]>
Date: Tue, 18 Apr 2006 15:57:24 +0300

Hello Tom Yu,

Thank you for reviewing the PANA WG documents. We appreciate the help.

Please see below for inlined comments.

>Russ has asked me to look at the "PANA Framework" I-D, among others 
>related to PANA.  I have read this document as a non-specialist.  As 
>such, some of the difficulties I encountered in understanding the 
>document may result from my lack of familiarity with the background 
>material.  My review will be at a somewhat high level, as I feel that I 
>lack the expertise to evaluate some of the finer details, and do not 
>feel that I understand the document sufficiently well to give a 
>thorough security review.
>
>The document cites RFC 4058 as an Informative Reference.  I found that 
>the content of the I-D to be rather incomprehensible without first 
>reading RFC 4058.  As such, I would suggest that RFC 4058 be cited as a 
>Normative Reference.  Even given RFC 4058, I found it difficult to 
>determine exact meanings of terms such as "network access".  Only 
>buried in Section 4.1.2 of RFC 4058 did I find that "network access"
>might be intended to mean "the ability to send and receive arbitrary IP 
>packets".

OK, we'll make RFC 4058 a normative reference.

>The motivations for PANA appear unclear to me from the I-D.  Reading 
>some combination of RFC 4058, in addition to the PANA WG charter, allow 
>me only a tenuous understanding of the motivations.  I will try to 
>summarize my reconstruction of the motivations.  One motivation appears 
>to be to enable a PaC with multiple data link capabilities to 
>authenticate and gain network access using any of its data links by 
>means of a unified encapsulating protocol.  This suggests that some of 
>the network access is meant to be controlled by a link-layer device.
>
>Another motivation for PANA (or perhaps it is inherited from EAP -- I 
>am not very familiar with EAP) appears to be to enable a more complex 
>architecture for authorizing network access.  The I-D suggests 
>scenarios where a mobile client may wish to connect to the Internet 
>from a multitude of data link access locations, each of which may be 
>operated by a different administrative entity, while the client may 
>wish to gain access to the Internet via a specific ISP with whom it has 
>an existing service subscription.  I suspect that this is to support 
>architectures such as having a DSL provider (who provides the client 
>data links) whose sub-IP network is distinct from the multiple ISP 
>networks to which it connects.

The following statement from RFC 4058 summarizes what PANA is:

"PANA would be a carrier protocol for EAP."

I admit we could have done a better job by calling it "an EAP lower layer"
and refer to RFC 3748 (where this term is defined).

The motivations behind PANA are documented in Appendix A of the RFC 4058.

>It appears that draft-ietf-eap-netsel-problem-03, cited in 
>pana-framework only as an Informative Reference, provides additional 
>necessary background material required to gain a good understanding of 
>the aforementioned complex network access architecture, and as such 
>should probably be cited as a Normative Reference.  A cursory reading 
>of eap-netsel-problem brings to mind the possibility of imposing an 
>Internet-scale routing problem at the data-link / access network level, 
>with associated complexity forced onto client implementations.
>It is also possible that I misunderstood the details of 
>eap-netsel-problem.

The EAP-netsel-problem I-D has somewhat a limited scope. It was meant to
capture the discussions held as part of designing an EAP-specific solution
as requested by 3GPP. We meant to expand on that work to be more
comprehensive, possibly under a new BoF/WG, but the EAP WG just wanted to
use that document to capture past discussions, not handle that problem space
in broader scope. With the current scope and status, I think it is best if
we treat that document as informational.  

>In Section 3, Figure 1 shows a diagram intended to describe the PANA 
>functional model.  It is not immediately clear whether, for instance, 
>the PaC is intended to communicate with the PAA via a pathway not 
>traversing the EP.  On the other hand, Figure 2 seems to suggest that 
>traffic between the PaC and the PAA is intended to traverse the EP.
>Accompanying text seems to favor the latter interpretation, though I do 
>not at this time have concrete suggestions for revising Figure 1.

I think we need to add some text to clarify this. The protocol/framework
does not mandate the EP be on the data path between the PaC and the PAA.
It'd be recommended to be that way, but not mandated (per protocol design).

>I am troubled by the repeated mentions of physical security.  My 
>understanding is that current IETF consensus (e.g., RFC 3552) is to 
>assume that an adversary has complete control of the communications 
>medium.  The overall architecture (or perhaps more accurately, plethora 
>of possible architectures) assumed by PANA allow the functional 
>elements (PaC, PAA, EP, AS) to be placed in multiple possible locations 
>in the network architecture, each of which has its own security 
>properties.  If this document is meant to provide guidance to operators 
>in designing networks, it should make more clear the complex security 
>properties of relationships among the functional elements and the 
>dependence of those properties on the locations of the functional 
>elements within the architecture.

I agree that we should provide some clarification on that. The only physical
security we are referring to is for the link between the PaC and the EP.
Physical security of the PAA and the AS are not relevant to PANA. And the
relevance of the former is mostly for whether a secure association protocol
is required (see Phase 2a in Figure 1 of draft-ietf-eap-keying-12.txt). [I
wish that EAP document could point out the optionality of the secure
association phase, and gave some guidelines -- so that we could simply point
at it]. The other relevance is due to EAP method selection, which is not
specific to PANA (as already stated in the document). 

>Section 11, the Security Considerations section, is very minimal, and 
>should be expanded to call out specific threats and analyses.  RFC
>4016 does not appear as a reference, though Section 11 here does refer 
>to draft-ietf-pana-pana-11, which allegedly contains security 
>considerations specific to the PANA protocol itself.  RFC 4016 probably 
>contains additional considerations specific to the architecture of an 
>access network which uses PANA, and some of these considerations should 
>probably be called out explicitly.

OK, we'll provide a reference to RFC 4016.

>
>It is not clear whether PANA is intended to provide assurances of 
>link-layer or network-layer data integrity or confidentiality to higher 
>layers, or even by what means such assurances are to be communicated.  
>Again, this is troubling in the context of repeated statements 
>regarding possible reliance on physical security.

These are relevant to "secure association" phases as illustrated in Figure 1
of draft-ietf-eap-keying-12.txt. PANA maps to the phase 1a in that figure.
1a is enabler of 2a/b, and it's the duty of 2a/b to enable L2/L3 data
integrity and confidentiality when needed.

Regards,

Alper

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana