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

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 14 Jan 2003 19:01:18 -0800

Bernard,

Thanks for your comments. See below..

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

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

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

> "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-pro
> blem-05.txt
> 
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.

> 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
> 
On a quick look,

	Where a lower layer ciphersuite is in use that provides per-packet
	integrity and authentication protection, or where the lower layer is
	considered physically secure, EAP may be considered secure from tamper-
	ing, and EAP Success and Failure packets may qualify as protected indi-
	cations.

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 ?

> 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-bind
> ing-01.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.

> 7.2.3
> 
> Authentication and integrity protection doesn't provide 
> replay protection
> -- this is a special property of the L2 ciphersuite.
> 
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 ?

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

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

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.

> 7.4. Service theft
> 
> Ultimately, this is about linking the authentication to 
> subsequent data
> traffic. Access control itself cannot provide this assurance 

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.

> -- it needs
> to come either from physical security or an L2 ciphersuite. I 
> think more
> detail is needed on this point.
> 

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

> 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.
> 
Ok. I am planning to remove it from the requirements.

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

thanks
mohan

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 17 Jan 2003 18:12:35 -0800

> > integrity. Is this a requirement for PANA?

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.

alper