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

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 20 Jan 2003 10:31:44 -0800

Bernard,
 
Thanks again for your comments.

> 
> 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.
> 
Ok, we will clarify this in the PANA requirements draft. 

> > > 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-rfc2869
> bis-06.txt
> 
Thanks for the pointer. I will add the reference and some text also.

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

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.

> 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.
> 
You bring up an important point. When i read the EAP-keying framework
document section 1, it says 

"The primary purpose of EAP is to authenticate an EAP client to an EAP
server, as well as to PROVIDE KEYS FOR USE WITH A LINK LAYER CIPHERSUITE
NEGOTIATED BETWEEN AN EAP CLIENT AND A NETWORK ACCESS SERVER".

I guess you are talking specifically about providing keys to secure
the link layer communication. Correct ? For PANA, as far as i can tell,
it is not a requirement to provide keys for the link layer ciphersuite.
From what i understand,  the details of how this will be done are
outside the scope of PANA. May be this should be clarified.

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

> > 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.
> 
Ok, i will clarify this.

> > 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
> 
Ok. I will go over it again.

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

Ok.

> > 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).
> 
If the method itself protects itself from replay, and not the EAP itself,
are there any vulnerabilities still ?

> > 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?
> 
I am not aware of this. Could the POTL authors comment on this ?

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

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

> > 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).
> 
What i meant was spoofing at layer 3. I can send packets meant for
IP address X, from IP address Y. Per-packet auth and integrity will
pass through but still the packets are spoofed at layer 3.

-mohan

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 29 Jan 2003 02:06:15 -0500

> I am not aware of this. Could the POTL authors comment on this ?

In PANA over TLS, session resumption from another IP address is also
possible.  In this case, DeviceID exchange over the TLS connection is
performed immediately after the session resumption in order to make
sure that there is no attacker sitting in the middle and has been
involved in the session resumption exchange.  By doing this, the two
entities can stop further negotiation performed for establishing an SA
for data traffic protection (e.g., IKE for establishing an IPsec SA)
which typically uses a device id as the SA identifier.  Of course, the
further negotiation to be performed after successful PANA
authentication needs to have its own device id protection mechanism.

Note that as a result of the recent discusion on the mailing list, the
protected DeviceID exchange can be optional when lower layer is
assumed to be secure.

Yoshihiro Ohba