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

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 15 Jan 2003 18:21:49 -0800

And this is the second message from Bernard. His comments on the
security threats draft.. (this is what Mohan had responded to..)

alper

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]
> Sent: Tuesday, January 14, 2003 10:36 AM
> To: [email-masked]
> Cc: Mohan Parthasarathy
> Subject: comments on draft-ietf-pana-threats-01.txt
>
>
> Section 3.0
>
> Device Identifier
>
> "PANA authentication agent keeps a table for binding device identifiers to
> the PANA clients"
>
> How is this binding done, exactly? Binding the
> authenticated identity to a device identifier requires that either the
> medium be physically secure (e.g. a wired link) or an underlying L2
> ciphersuite that provides support for per-packet authentication and
> integrity. Is this a requirement for PANA?
>
> Section 6
>
> "The path between the PAA and AS"
>
> While it is reasonable to assume that the AAA protocol provides per-packet
> authentication and integrity protection, it may *not* provide
> confidentiality. So we need to be more specific about what it means to say
> that the path is "secure". For example, it is generally considered that
> RADIUS is *not* secure against an attacker who can snoop a large number of
> packets, where the PAA shares a RADIUS shared secret with a NAS that uses
> PAP. Also, within RADIUS an attack snooping on the PAA/AS path can
> determine the location of users at any point in time (via accounting
> records).
>
> In this section I'd include other attacks, such as session hijacking,
> downgrade attacks, etc. A sample threat analysis is
> included within Section 7 of RFC 2284bis-09:
>
> http://www.drizzle.com/~aboba/EAP/draft-ietf-pppext-rfc2284bis-09
>
> Section 7
>
> In IEEE 802.11i discovery (Beacon, Probe Request/Response) doesn't need to
> be protected because the discovered capabilities are included in a
> subsequent secured exchange, allowing spoofing to be discovered after the
> fact. That exchange (the 4-way handshake) supports both protected
> ciphersuite & capabilities negotiation as well as transient session key
> derivation and "liveness" guarantees. You might think about the
> requirements for detection of spoofing after the fact.
>
> "If mutual authentication is performed i.e., client to AS and AS to
>    client, via the PAA, the successful authentication response from the
>    AS can be used to validate the authenticity of the PAA."
>
> This isn't really true -- you need to provide mutual authentication
> between all entities in the protocol; transitive trust between PAA and PAC
> can't be assumed just because the PAC and AS have mutually authenticated
> and the AS and PAA have mutually authenticated. See the EAP Keying
> Framework for details:
>
> http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-05.txt
>
> 7.2.1 Spoofing success or failure
>
> There is a new section in RFC 2284bis (4.2.1) that deals with this. Please
> read it and tell us ([email-masked]) whether it is helpful:
>
> http://www.drizzle.com/~aboba/EAP/draft-ietf-pppext-rfc2284bis-09.txt
>
> 7.2.2 MiTM
>
> MiTM actually requires cryptographic binding between the keys and the
> endpoints. This is typically accomplished in mutual authentication, but
> *not* by two independent one-way authentications as occurs in some of the
> tunneled EAP methods. Some more detail here or a reference might be
> appropriate, such as to:
>
> http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-01.txt
>
> 7.2.3
>
> Authentication and integrity protection doesn't provide replay protection
> -- this is a special property of the L2 ciphersuite.
>
> 7.2.4
>
> What specifically provides protection against address spoofing is where a
> key has been derived that is bound to the MAC address. Then if the MAC
> address is changed, a different key will be used to attempt to verify the
> MIC, and this verification will fail. So the implication is that the
> underlying ciphersuite MUST have a MIC (not all do, such as WEP).
>
> 7.3. Spoofed disconnect
>
> Not all disconnect messages are protectable. For example, in 802.11,
> Disassociate and Deauthenticate are not protected even in IEEE 802.11i.
> This is also discussed in RFC 2284bis-09.
>
> 7.4. Service theft
>
> Ultimately, this is about linking the authentication to subsequent data
> traffic. Access control itself cannot provide this assurance -- it needs
> to come either from physical security or an L2 ciphersuite. I think more
> detail is needed on this point.
>
> 7.5 DoS resilience
>
> I think you need to be very clear on the types of DoS attack that you want
> to protect against. In practice, DoS attacks are hard to protect against,
> so saying "PANA MUST be resistant to DoS attacks" is not very practical.
>
> Instead, I would argue that you need to distinguish the types of DoS
> attack:
>
> a. Attacks that require the attacker to be within range of an access point
> b. Attacks that can be carried out from afar
> c. Attacks that allow an attacker to consume signfiicant resources on the
> PAA or AS with relatively minimal effort (e.g. forcing a public key
> calculation on the PAA or AS)
>
>
>
>

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 20 Jan 2003 09:49:22 -0800

Bernard,

> 
> > Just to clarify one point... In the absence of physical security or
> > L2 ciphersuite capabilities, IPsec can be used to provide
> > per-packet authentication and integrity check following the
> > initial authentication.
> 
> That's fine, but then the binding has nothing to do with 
> PANA, per se but
> rather is established via IKE, no?
> 
Yes, that is my understanding as per the discussion sometime back in this group.
But there may be lot of details missing like how IKE (between PaC and EP)
uses the information like keys, credentials etc. that was used during the PANA
exchange to set up a SA to secure further communication. We thought that this
was outside the scope of PANA working group but an informational draft on
how this can be done might be produced by this group. 

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 20 Jan 2003 14:34:47 -0800

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

> > 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?
> 
By setting up SAs. Once the authentication is complete, it is assumed that
keys can be derived using the EAP framework (this is where PANA needs to
provide additional details for 4-way) and that can be used as input to
securing the future communications. I agree that these details
are missing as to how this will happen. The service theft section discusses
this to the extent that there are vulnerabilities but it does not
go into details about what could be done as it was outside the scope of
the threats evaluation document itself. It says ".... PANA should be able
to provide keys...". I will clarify this further. 
 
> > 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.
> 
Ok. 

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

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

> > 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.
> 
Ok. Perhaps, we should revisit to see why PAA and EP cannot be always
co-located.

thanks
mohan