eap Mailing List: Issue 294: Rewrite of Security Considerations and Requirements

[Bernard Aboba (aboba]

This is a fairly big issue (probably will need to split into several
issues to resolve it), but now that we have the AAA Key Mgmt. document, it
is possible to evaluate whether existing EAP usage satisfies the requirements.

Here is a list of the requirements from
draft-housley-aaa-key-mgmt-00.txt:

MANDATORY

1.    Cryptographic algorithm independence
2.    Strong, fresh session keys
3.    Key scope limitation
4.    Replay protection
5.    Authenticate all parties
6.    Peer and authenticator authorization
7.    Keying material confidentialitiy
8.    Confirm ciphersuite selection
9.    Uniquely name keys
10.   Prevent the domino effect
11.   Bind the key to its context

RECOMMENDED

12.   Confidentiality of identity
13.   Authorization restriction

Below find detailed notes on EAP usage over various media:

A. PPP
B. 802.1X-2004
C. IEEE 802.11i

My overall take is that PPP and 802.1X-2004 do not meet quite a few of the
security criteria.  If these protocols were to be used over shared
media (e.g. PPPOE over wireless) or an attacker can snoop backend
RADIUS traffic, some fairly serious security vulnerabilities would
result. However, in other scenarios (e.g. wired switched infrastructure
with RADIUS/IPsec and no proxies) the deficiencies may not be so bad.

Here are the details of the assessment:

A. EAP over PPP [RFC3748]

1. PPP with ECP can negotiate multiple cryptographic algorithms.  Diameter
and RADIUS over IPsec can also negotiate multiple algorithms (naked RADIUS
cannot).

2. Given a suitable EAP method, strong fresh session keys can be derived.
This is also true for Diameter or RADIUS over IPsec.  RADIUS by itself
uses a long-term secret that is not fresh.

3. There is no key caching in PPP, so I think that key scope is not an
issue.

4. PPP ciphersuites typically support replay but not integrity
protection.  If an EAP method supports replay and integrity this
requirement is satisfied for the EAP exchange at least.

5. PPP does not support mutual authentication of the peer and
authenticator.  If a suitable EAP method is chosen, mutual authentication
between the EAP peer and server is supported.

6. PPP does not support a post-EAP exchange, so I don't think
authorization is provided.

7. Assuming that there are no RADIUS proxies or Diameter EAP is used with
re-direct, key confidentiality can be supported.

8. PPP ECP does not support secure confirmation of the "best" ciphersuite.

9. PPP does not support key naming, but since it does not support key
caching, I'm not clear that this is really required.

10. PPP doesn't share keying material between authenticators.  So I think
this requirement is satisfied, no?

11. PPP doesn't support a post-EAP exchange, so I think that the binding
requirement isn't satisfied.

12. If an EAP method supporting Identity privacy is selected, this
requirement can be satisfied.

13. Since PPP doesn't support a post-EAP exchange, there is no way to
synchronize authorizations.  However, since key caching is not supported
I'm not clear this is a big issue.

B. EAP over 802.1X-2004

1. In wired 802.1X there are no ciphersuites used to protect data, so
negotiation of multiple algorithms is not relevant.

2. Given a suitable EAP method, strong fresh session keys can be derived.

3. There is no key caching in wired 802.1X, so I think that key scope is
not an issue.

4. Since there are no ciphersuites, I don't think replay protection is
an issue, assuming that the EAP method supports replay protection.

5. 802.1X-2004 does not support mutual authentication of the peer and
authenticator.  If a suitable EAP method is chosen, mutual authentication
between the EAP peer and server is supported.

6. 802.1X-2004 does not support a post-EAP exchange, so I don't think
authorization is provided.

7. Assuming that there are no RADIUS proxies or Diameter EAP is used with
re-direct, key confidentiality can be supported.

8. 802.1X-2004 does not support secure confirmation of the "best"
ciphersuite.

9. 802.1X-2004 does not support key naming, but since it does not support
key caching, I'm not clear that this is really required.

10. 802.1X-2004 doesn't share keying material between authenticators.  So
I think this requirement is satisfied, no?

11. 802.1X-2004 doesn't support a post-EAP exchange, so I think that the
binding  requirement isn't satisfied.

12. If an EAP method supporting Identity privacy is selected, this
requirement can be satisfied.

13. Since 802.1X-2004 doesn't support a post-EAP exchange, there is no way
to synchronize authorizations.  However, since key caching is not
supported I'm not clear this is a big issue.

C. EAP over IEEE 802.11i

1. IEEE 802.11i supports ciphersuite negotiation.

2. Given a suitable EAP method, strong fresh session keys can be derived.

3. IEEE 802.11i does not synchronize the key scope, since the
authenticator knows the scope, but the peer does not.

4. IEEE 802.11i does support replay protection on all ciphersuites
(TKIP, AES CCMP).

5. IEEE 802.11i supports mutual authentication of the peer and
authenticator in the 4-way handshake.  RFC 4017 reuqires selection of an
EAP method supporting mutual authentication between the EAP peer and server.

6. IEEE 802.11i does synchronize some aspects of authorization
in the 4-way handshake.  However, without management frame
protection other aspects may not be synchronized (e.g. an error
in the Association-Response or Reassociation-Response cannot be
verified).

7. Assuming that there are no RADIUS proxies or Diameter EAP is used with
re-direct, key confidentiality can be supported.

8. IEEE 802.11i securely verifies selection of the "best"
ciphersuite.

9. IEEE 802.11i supports key naming (e.g. PMKID) but it is
based on a hash of the key name.

10. IEEE 802.11i doesn't share keying material between
authenticators.

11. IEEE 802.11i doesn't provide a complete key binding because
the peer doesn't know the authenticator identity and the key
lifetime isn't synchronized.

12. If an EAP method supporting Identity privacy is selected, this
requirement can be satisfied.

13. IEEE 802.11i does require that authorizations be part of the
PMKSA, which prevents elevation of privilege.