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

From: Subir Das <[email-masked]>
Date: Sun, 19 Jan 2003 22:45:09 -0500

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

On Tue, 14 Jan 2003, Mohan Parthasarathy wrote:

> If the path between PAA and EP can be secured which is quite possible,
> it will be used by the yet-to-be defined protocol that distributes the
> information from PAA to EP. Perhaps, we need to reflect this in the
> PANA requirements that path PAA and EP should be secured rather than
> stating it as an assumption in this draft.

Yes, I think that makes sense.

> > http://www.drizzle.com/~aboba/EAP/draft-ietf-pppext-rfc2284bis-09
> >
> Ok. I did not find any attacks specific to NAS-AAA path in section 7.
> Would it be better if it can reference the above draft for threats
> in this path ?

For threats in the NAS-AAA path, you might look at:

http://www.ietf.org/internet-drafts/draft-congdon-radius-8021x-21.txt
http://www.ietf.org/internet-drafts/draft-aboba-radius-rfc2869bis-06.txt

> Ok. The requirements does not state that the discovery process
> must be protected. It just states that PANA cannot assume it and hence
> you need the ability like in 802.11i to verify it. The above one
> assumes that you can derive keys so that you can do a secure exchange
> later. It may not be possible with all EAP methods. So, it may not
> be always possible. Correct ? Do you want me to include the above
> scenario as an example to make it more clear ?

I think there is a question of whether methods which don't mutually
authenticate or use keys are usable with PANA. I'd suggest that the
requirements should say something about that. One important assumption
for
EAP keying and security is that for physically insecure media there is a
"third leg" -- mutual authentication between the NAS and client. If PANA
does not assume physical security, then I think it may have to define a
third leg running over IP. If so, this is an important requirement.

> The above text was in the "PAA discovery" section. I think i will remove
> it from here as it is more talking about solution here.

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.

> When EAP is used at the IP level, having lower layer ciphersuite that
> provides per-packet protection is not sufficient as any node can still
> spoof a success or failure.  So, there should be a MIC as part of EAP itself.
> Correct ?

Yes. We've attempted to clarify this in -10:

http://www.drizzle.com/~aboba/EAP/draft-ietf-pppext-rfc2284bis-10.txt

> The reason i was not referring to this is because it was getting specific
> to the details like tunneled EAP methdod. This draft was supposed to
> more generic. I can still add it if it would help.

Even in a generic framework you still need to understand what the
requirements are for EAP transport and method use, and what the trust
model is. If these questions are not answered now they will come back
again and again (we've been there with IEEE 802.11i).
> I am not sure i understand this comment. I was only making a point that
> even if layer 2 provides replay protection (which is what i was trying to
> say but it says different) it is not sufficient, as PANA messages can
> potentially still be replayed. Could you clarify your comment ?

OK. Yes, they could be replayed at L3. I think this translates into an
EAP
method requirement for replay protection, because EAP itself doesn't
provide replay protection (the Identifier value is not required to be
monotonically increasing).

> Ok, i will add that. But you still need to prevent yourself from the attack
> of someone modifying the IP address. POTLS prevents it by having a separate
> exchange after a secure session is setup between PaC and PAA.

Actually, I'm not sure you really need to prevent that. For example, in
POTL, a fast resume could occur from another IP address -- is this
forbidden?

> This was more talking about the PANA disconnect notification mechanism as mentioned
> in the PANA requirements. So, even if layer 2 does not have one, PaC will still
> generate a disconnect at the PANA level which should be protected.

Not sure what security value this has -- POTLS can of course be
disconnected by an attacker by spoofing a RST.

> I agree that access control in terms of filtering IP/MAC address will
> not provide this. But the requirement states that PAA can provide access
> control information like "keys" to EP which in turn can enforce the
> service theft. The idea is that these keys can be used further to establish
> an SA between PaC and EP that can prevent service theft.

If PANA is generating keys then you definitely need to be very clear
about
what kinds of keys they are and the trust relationships between the
entities. Or does PANA inherit the EAP keying framework? The problem is
that PANA has more entities, so it isn't entirely clear to me that this
framework can be applied to PANA, since it only covers 2-way and 3-way
exchanges, not 4-way.

> L2 ciphersuite will prevent unauthorized access but not injecting false
> data. Ok, i will try to expand this section a bit more.

It can, if the L2 ciphersuite includes per-packet authentication and
integrity protection. For example on 802.11 TKIP, WRAP and CCMP do
provide
this, but WEP doesn't. On PPP none of the ciphersuites provide this
(though they do provide confidentiality).