Subject: [Fwd: RE: comments on draft-ietf-pana-threats-01.txt]

From: Subir Das <[email-masked]>
Date: Mon, 20 Jan 2003 17:33:08 -0500

-------- Original Message --------
Subject: RE: comments on draft-ietf-pana-threats-01.txt
Date: Mon, 20 Jan 2003 17:18:17 -0500 (EST)
From: Bernard Aboba <[email-masked]>
To: Mohan Parthasarathy <[email-masked]>
CC: [email-masked]

> In the past discussion, when this came up some folks thought that PANA itself
> will not restrict the use of EAP methods. This means if you choose method X,
> then you get some level of protection i.e still vulnerable to certain attacks.

Since PANA is used in many scenarios, it might not be appropriate to add
restrictions that apply to only some cases. But guidance seems
appropriate
-- wireless media are very different from wired media in the security
requirements and they can't be treated the same way.

> I guess you are talking specifically about providing keys to secure
> the link layer communication. Correct ?

Yes. This allows the authentication to be bound to subsequent per-packet
integrity and authentication, preventing hijacking. It also enables
features such as fast handoff.

> For PANA, as far as i can tell,
> it is not a requirement to provide keys for the link layer ciphersuite.

So how do you prevent hijacking?

> Perhaps we need something like EAP-keying framework for PANA also and
> some informational document on how to secure the communication.

I think so. As it stands, it is not at all clear to me what security
assurance PANA provides, if any.

> > The question about the PANA trust model remains. As mentioned above,
> > transitive trust probably isn't a strong enough model when
> > dealing with
> > media which aren't physically secure.
> >
> Ok, i will clarify this.

This is part of the overall security framework, I think. You need to
know
what threats PANA is trying to address on various media, and what the
requirements are.

> If the method itself protects itself from replay, and not the EAP
> itself, are there any vulnerabilities still ?

There could be. I think it depends on the method behavior. For example,
a
method that silently discards a replayed packet should be ok. But if it
aborts on MIC failure or replay then it could be disabled by a single
forged packet. That would enable an attacker to force multiple
authentication operations as the result of a single forgery -- good
leverage for a DoS attack.

> Ah! missed that completely..It is useless to provide layer 3 protection
> if layer 2 can be used to disconnected. Ok, i will have to redo the
> requirement on this one.

Not quite useless... but vulnerabilities will remain.

> The difference i see is this:
> In EAP-keying framework, the trust relationships involved are Client-NAS,
> NAS-AAA, Client-AAA.
> In PANA, we have PaC-PAA, PAA-AAA, PaC-AAA and the fourth one i think
> you mention is PAA-EP. Note that it is still possible to have PAA and
> EP co-located in which case it will boil down to the same as EAP-keying
> framework. If not we may have to produce another document similar
> to EAP-keying framework document to expand on the key derivation.
> I will add some text to this effect. Does that make sense ?

Yes, it does. But adding another party adds a *lot* of complexity. We
are
having some trouble nailing down the EAP 2-way and 3-way exchanges.
Trying
to prove the security of a PANA 4-way exchange could be very difficult.