Subject: [Pana] RE: [secdir] Last Call: 'Protocol for Carrying Authentication for Network Access (PANA)' to Proposed Standard

From: "Alper Yegin" <[email-masked]>
Date: Thu, 20 Apr 2006 16:00:27 +0300

Hi Tom,

Thank you, this time for your PANA review.

Please see below.

> Tom Yu wrote:
> 
> >Russ has asked me to look at the "PANA" protocol I-D, among others.  I
> >apologize for the lateness of this review; the document has not been
> >an easy one for me to read.
> >
> >Editorial nit: AVP is not expanded prior to its first use.  There are
> >probably other forward references that could use correction; I did not
> >read this document with copyediting as a goal.

We'll fix that and look for others.

> >Some aspects of the security of PANA appear to be reasonably
> >designed.  Other aspects could be problematic.
> >
> >The mechanism of using sequence numbers for prevention of blind
> >spoofing denial-of-service attacks seems reasonably sound to me.  The
> >initial sequence number is not required to be cryptographically
> >strong, but this may not be a significant problem.  The use of cookies
> >to enable statelessness on the PAA also seems reasonable.  The
> >Session-Id also appears to afford some protection against blind
> >spoofing prior to the establishment of a shared key between PaC and
> >PAA.
> >
> >It is not clear whether PANA requires mutual authentication from the
> >underlying EAP mechanism.  I'm not sure how much of a problem this
> >might be.  There are many options for how PANA may be deployed, e.g.,
> >whether the EAP method produces a AAA-key, or what the link-layer or
> >physical security capabilities are.  I was unable to find any
> >reasonably complete treatment of the security implications of the
> >interactions of particular deployment choices.  Some security
> >considerations related to deployment choices are covered in
> >pana-framework, but interaction of implementation behavior with
> >deployment security parameters should be clearly documented somewhere.
> >It's also not clear that an implementor can provide an operator a
> >simple interface for communicating the relevant deployment-specific
> >security parameters.

The selection of an EAP method to be used with PANA is outside the scope of
PANA design. This issue has applicability to any EAP lower layer, and there
is no specific design aspect of PANA to make a difference in that respect.
We captured that in Section 9 of the PANA Framework document. The same can
be said for other EAP lower layers, such as IEEE 802.1X, PKMv2, IKEv2. It'd
be more appropriate to capture such aspects in more general documents
outside PANA WG.

We haven't designed an interface (an API?) for configuring the PaC/PAA/EP.
I'm not sure one is needed. 

> >In Section 5.11, "Error Handling", and in other places, the receiver
> >of an error lacking an AUTH AVP is required to process the error
> >without changing its internal state, if the lower layer is insecure.
> >It is not clear how the receiver implementation is supposed to make
> >that determination.  Clearly, an implementation could probably detect
> >whether there is cryptographic protection at the link layer, but the
> >repeated mentions of physical security lead me to believe that the
> >authors intend for purported physical security to be factored into any
> >decision concerning whether to change state upon receipt of an error
> >message.  Elsewhere, the document indicates that the PAA has
> >knowledge, possibly configured by the operator, of whether the link
> >layer is "secure"; therefore, I assume the PaC's ability to determine
> >link-layer security would be the primary issue.

This goes back to the configuration issue. I cannot imagine the PANA
implementation dynamically discovering the lower layer capability. For that,
we need to have a configuration (file). Let us capture that in the
specification.

> >The way that PANA could interact with lower-layer security makes me
> >uncomfortable.  The ability to separate the EP and PAA functions into
> >separate entities appears to have some problematic consequences; for
> >example, the PAA needs to instruct the EP to pass traffic from the
> >PaC, but under some circumstances this can only occur by the PaC's
> >_assertion_ of its Device-Id.

And when necessary, this needs to be compounded (or, protected) by
cryptographic means. We captured that in 4.1.4 of RFC 4058, and the PANA
Framework document mentions that in several places.

> >PANA appears to circumvent the channel binding problem by essentially
> >inverting the usual conception of channel bindings; it allows
> >bootstrapping the keying of lower layers once authentication has
> >completed.  This of course assumes that the EAP method produces an
> >AAA-key.  This inversion of the usual channel binding concept could be
> >problematic; I believe that usually security in lower layers is
> >assumed to be established before security in upper layers is
> >established.

We'd be interested to know if you see specific issues with this. And I'm
wondering how different this is from enabling IPsec by first running IKE
(over UDP/IP).

> >Device-Ids which are not link-layer addresses or IP addresses are
> >potentially problematic.  If point-to-point links of various sorts are
> >used, the EP probably knows its own Device-Id and the Device-Id of the
> >PaC, but the PaC might not have any way of knowing its Device-Id as
> >seen by the EP.  If there are end-user means for configuring non-IP,
> >non-link-layer addresses as Device-Ids into the PaC, I can't imagine
> >that they would be very user-friendly, as they would likely involve
> >knowledge of the configuration of the EP.

Such Device-IDs have only local significance (as stated in Section 5.7).
They are not meant to be exchanged with the peers. They are used locally to
associate PANA sessions with the local interfaces. [I think these last two
sentences can be added to the text].

> >Even worse, as far as I can tell, with a configuration involving a
> >separated EP and PAA, the PAA has _no_ authenticated means of knowing
> >the Device-Id of the PaC except by assertion by the PaC (once
> >authenticated).  I don't think the EP is supposed to act on the
> >PaC<->PAA traffic in any way except as something like a link-layer
> >switch or IP router.  The EP thus cannot directly participate in the
> >PANA protocol in any way that would bind its perception of the PaC's
> >Device-Id to the security association (if any) built during the PANA
> >authentication.

If EP and PAA are separated and we are using locally significant Device-Ids,
then EP and PAA may have hard time indexing the PaC. I mean, how can PAA
tell the EP that "this PaC" shall be allowed to access the network? 

In that case it might appear that EP-PAA separation and locally-significant
Device-Ids don't mixup. But that's not always so. In various wireless
architectures, the EP (a base station) and the PAA (access gateway) are
separated, and the PaC (mobile terminal) traffic is tunneled between the
base station and the access gateway. The tunnel also has an attribute to
identify the mobile terminal (a session id, etc.). That'd be leveraged by
the PAA and the EP to index the PaC.

OK, we need to capture this in the document as well. 

> >If the EP and PAA are separate, it appears that the PaC's assertion of
> >its Device-Id is only really useful if it can be used, in conjunction
> >with keying material produced by the EAP method, for the purpose of
> >link-layer security or IPsec.  

I don't think cryptographic per-packet security is a mandate if EP and PAA
are separated. Think of wired Ethernet in enterprise networks. EP can be on
the Ethernet access switch, PAA somewhere else. We can retain the
non-cryptographic (physical) security used in such networks today.

> > If keying of link-layer security or of
> >IPsec does not occur, then it appears that the security is actually
> >_diminished_ from the case where EP and PAA are co-located; if they
> >are co-located, the PAA can obtain a trustworthy notion of the PaC's
> >Device-Id.

Regards,

Alper

> >_______________________________________________
> >secdir mailing list
> >[email-masked]
> >https://mailman.mit.edu/mailman/listinfo/secdir
> >
> >
> >
> >

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

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 21 Apr 2006 01:08:12 +0300

Thank you Bernard for your review.

Please see below for inlined responses.

>I also read the document, and have to admit that I was very puzzled by 
>the deployment scenarios that were being presented.  Maybe it's just
>me, but I just couldn't figure out why an ISP would want to deploy PANA.  
>At a minimum, I think the authors need to do a better job of presenting 
>PANA's advantages and making the case for its adoption. 

The brief problem statement was captured in RFC 4058. For a more detailed
advantages discussion, I don't think protocol specification or the framework
documents are appropriate. Instead, we captured that in an FAQ. Please see
http://panasec.org/docs/PANA-FAQ.txt, question #3.

>One way the clarity of the document could be improved is
>by moving much of Section 4 up earlier in the document, since this
>section gets into the deployment scenarios envisaged for PANA. 

OK, we'll do that.

>As far as I can tell, there are two major deployment scenarios: 
>
>   a. Networks where a secure channel is already available prior to
>   running PANA
>
>In this case, the document states: 
>
>"     The PANA session can be bound to the communication channel it was
>      carried over."
>
>The use of the term "bound" is unfortunate here, because the term is 
>typically used to imply some sort of cryptographic binding, which doesn't 
>seem to be the case.  Rather, I think that the implication is that the 
>PANA session is used to provide per-port authentication on the channel. 

Maybe we should use another term, like "associated"?

>DSL is given as an example of this scenario.  However, for DSL, PPPOE has
>become quite popular, an approach which enables multiple users on a single
>wire (and traffic separation between them).  As a result, it seems to me
>that the "physical security" or "secure channel" assumption may in 
>practice prove quite restrictive. 

In the case of PPPoE, the "wire" you are referring to is the one between the
BRAS and the CPE (DSL modem) I believe. That's physically secured from
outsiders, but shared among hosts sitting behind the CPE. Unless that is
compounded by either physical or cryptographic security between the CPE and
the host (which is another piece of wire or radio link), we cannot prevent
hosts behind the CPE posing security threats to each other. So the "secure
channel" in the case of PPPoE needs to be end-to-end between the BRAS and
the end host. And that channel does not carry multiple users on it, only
one.

>The authors need to make it more clear why an ISP would want to deploy
>PANA in this scenario, as opposed to say, PPPOE. 

DSL Forum is looking at deployments without PPP (and PPPoE). For that, if
you have access to the DSL Forum documents, please take a look at  the
contribution dsl2006.174.02. The document talks about authentication
requirements for such non-PPP-based deployments. That'll also shed some
light to your first question.

>   b. Networks where a secure channel is created after running PANA
>
>This scenario seems to involve either keying of link-layer ciphersuites
>(e.g. 802.11i), or IPsec (via IKEv1 or IKEv2 binding).  However, my
>understanding is that IEEE 802.11i does not allow IP traffic to pass
>prior to completion of link layer authentication, so I'm not sure that 
>the 802.11 deployment scenario is viable.  

Currently carrying PANA over the uncontrolled port is under discussion with
IEEE. The IEEE 802.11i specification has conflicting statements with respect
to whether this approach is allowed or not (see
http://www1.ietf.org/mail-archive/web/ietf/current/msg41011.html). We'll
revise the I-D based on the IEEE resolution. 

Aside from that, please note there is another mode of operation described in
the PANA Framework document which relies on "virtual open-access AP" (see
Section 10.2.2). We verbally confirmed with the IEEE members who were
present at the last PANA meeting that this scheme was feasible. We'll do
necessary revisions per IEEE feedback.

> I also found myself puzzling
>over the IKEv1/IKEV2 deployment scenarios as well. 
>
>Some more specific comments: 
>
>"IPsec can be used for per-packet security, but nevertheless it is not the 
>only way to achieve this functionality.  Alternatives include reliance on
>physical security and link-layer ciphering."
>
>This sentence left me puzzled.  There is already an existing standard for 
>use of EAP with IPsec: IKEv2.  Since link layer authentication does not 
>bring the link to an "up" state prior to completion of authentiation, I do 
>not understand how it is possible to use PANA to key link-layer 
>ciphersuites; this would seem to require an IP interface to be operable 
>while the link was "down". 

A given L2 can be designed to allow limited IP access to unauthenticated
hosts so that they can use this pinhole to get authenticated. This is very
much akin to how 802.11 L2 allows transporting EAPOL frames but nothing else
until the station is authenticated, or how an IPsec gateway talks IKE/UDP
with the VPN client but no other non-IPsecured traffic is allowed. 

>"When the server for PANA and per-packet
>access control entities are separate, SNMP [I-D.ietf-pana-snmp] may
>be used to carry information between the two nodes."
>
>Given the issues with deployment of SNMPv3, having PANA depend on SNMPv3
>seems risky, and if earlier versions of SNMP are used (e.g. SNMPv2) it 
>seems like this could create a security problem. 

We had a long discussion among candidates, such as RADIUS, COPS, Diameter,
SNMP, and finally settled for SNMPv3. While this is the only protocol IETF
PANA WG is specifying for PAA-to-EP signaling, a given deployment is not
constrained by this choice only. In fact, several wireless architectures
already have their own version of such a provisioning protocol, that runs
between the access points (or, base stations) and the NAS. E.g.: R6 in
WiMAX, Rp in 3GPP2, etc. Those that don't have such interfaces have the
option to deploy and use SNMPv3 (or invent their own, as usual). So, I'd not
say PANA depends on SNMPv3. 

>"If the client for
>PANA configures an IPsec tunnel for enabling per-packet security,
>configuring IP addresses inside the tunnel becomes relevant, for
>which there are additional choices such as IKE [RFC2409]."
>
>Since IKEv2 already handles tunnel setup as well as EAP authentication,
>I was somewhat confused by this.  Why would PANA be needed in such a 
>scenario? 

IKEv2 does not satisfy the requirements that were set in RFC 4058, most
importantly 4.5.1. For that, and for the various other features of PANA, I
don't think IKEv2+IPsec can substitute PANA+IKEv1/IKEv2+IPsec. That's not to
say there wouldn't be any deployments using the former suite.

>Pre-PANA address (PRPA)
>
>The concept of a "pre-PANA address" does not make sense to me in a 
>link-layer authentication scenario, since the link is not even "up" at the
>time that PANA operates.  How can a host obtain an IP address on a link
>that is not in the "up" state?  The Internet layer simply is not 
>functional. 

I presume you are again referring to enabling link-layer ciphering by
EAP/PANA, right? If so, please see my earlier response.

>"Examples of secure
>association protocols include the 4-way handshake in IEEE 802.11i
>[802.11i], and IKE [RFC2409] in IPsec-based access control."
>
>While IKEv2 can serve as a secure association protocol for EAP, I
>don't understand how IKEv1 could be used for this.  
>
>The problem is that the scope of EAP keying material is defined
>by the authenticator identity advertised by the PANA authenticator (PAA). 

No, the key scope on the network side is defined by the list of Device-Ids
(IP addresses of the IPsec gateways in this case) sent by the PAA. 

>However, the binding of the pre-shared key differs within IKEv1, depending
>on the mode in use.  For example, in Main Mode, the pre-shared key is
>bound to an initiator IP address; in Aggressive Mode it is bound to an
>Initiator ID payload.  
>
>The lack of consistency between IKEv1 modes creates a problem because it
>implies that the PAA needs to advertise different authenticator identities 
>depending on the IKE mode in use.  However, the PAA cannot necessarily
>know which mode will be used, so it's not clear to me how it can announce
>an authenticator identity that can be guaranteed to work in all IKEv1 
>modes.  

Please see http://ietf.org/internet-drafts/draft-ietf-pana-ipsec-07.txt
Section 6 for the relevant details. If there is a problem we can fix in that
document.

>Also, as a practical matter, the IKEv1 pre-shared key is not typically
>implemented as a dynamic key.  For example, in FIPS 140-2 compliant
>implementations its configuration may be restricted to the 
>Crypto-Operator. 

I'm not familiar with FIPS 140-2 requirements. I'd appreciate if you can
give a pointer to the relevant details (crypto-operator, etc). Is this
something that IETF protocols must comply with? 

>I think these issues could make it difficult to deploy PANA with IKEv1. 
>Since IKEv2 already supports EAP, I am not clear why IKEv2/EAP would
>not be used as the mechanism for keying of IPsec SAs, rather than 
>PANA. 
>
>"     The EP uses non-cryptographic or cryptographic filters to
>      selectively allow and discard data packets.  These filters may be
>      applied at the link-layer or the IP-layer [I-D.ietf-pana-ipsec]."
>
>I do not understand the value of applying non-cryptographic filters for
>access control, since an attacker can simply change its source address
>and thereby access the network without impediment.  

Only if it knows the address of the victim... And that is not practical when
privacy of the communication channel is provided by the lower layers (e.g.,
wired Ethernet deployments in enterprise networks).

>"Physically secured networks (e.g.,
>DSL) or the networks that are already cryptographically secured on
>the link-layer prior to PANA run (e.g., cdma2000) do not require
>additional secure association and per-packet security.  These
>networks can bind the PANA authentication and authorization to the
>lower-layer secure channel that is already available."
>
>The document does not describe how PANA is bound to lower-layer security
>associations, and in fact, I am not clear that this kind of
>binding is permitted by those specifications.  For example in
>IEEE 802.11i, the keys are purely determined by the EAP exchange
>encapsulated within IEEE 802.1X;  any PANA exchange run on
>top of the lower layer will have no effect on the authenticator
>key cache, as it appears to the lower layer to be just another
>data flow.  Therefore I'm not clear what "bind" means in this
>context.  

I think "associate" is a better term. We should associate the PANA session
with the channel. 

>"The PaC MUST dynamically or statically configure an IP address prior
>to running PANA."
>
>In a lower layer scenario this is impossible, because the link is not
>up yet.  Am I missing something? 

Please see my earlier response.

Regards,

Alper