Subject: [eap] Summary of Key Scoping issues (fwd)

From: Bernard Aboba <[email-masked]>
Date: Fri, 5 Sep 2003 10:04:25 -0700 (PDT)

---------- Forwarded message ----------
Date: Thu, 04 Sep 2003 20:52:24 +0300
From: Jari Arkko <[email-masked]>
To: [email-masked]
Subject: [key-design] summary of issues

Here's a quick list of some question marks we've had in the mail
discussion, together with some tentative answers people
have given. But lets start with a reminder of documents
and the problems we are solving:

Here are references to relevant documents:
- EAP Key Framework Document:
   http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-07.txt
- IEEE 802.11i D5:
   http://grouper.ieee.org/groups/802/11/private/Draft_Standards/11i/802.11i-D5.0.doc
   Username: p8021, Password: go_wildcats

PROBLEM STATEMENT

EAP was originally designed for use in environments
where keys where not needed. The current and planned
use of EAP apply keys generated as a side effect of EAP
authentication to e.g. link layer protection. However,
there are significant security issues involved in the use
of keys, particularly in environments where the authentication
is performed in a distributed system involving APs and AAA
servers. It becomes necessary to think about how the
keys can be given to APs without damaging the system
level security properties. Similarly, the use of EAP "SAs"
in fast handoff scenarios makes it necessary to think about
where such the keys can be reused and under what conditions.

A preliminary definition of issues and a framework for
key usage has been outlined in draft-aboba-pppext-key-problem-07.txt.
A number of open issues is still left with the document, however,
and it hasn't received enough review. The EAP Keying Design Team
should complete the document.

GENERAL

1. Scope of the work.  It's clear that we can't provide
    WLAN access that is "completely secure" against access
    point compromise--an attacker who compromises an AP
    can always do bad things.

    Tentative answer: I don't think we should worry about
    "completely secure," because absolute or complete security
    is not a coherent idea. A reasonable goal is developing
    some confidence that the design protects against all known
    attacks. Russ' requirement was compromise of one AP should
    cannot lead automatically to compromise of all traffic
    flowing through any other AP, a property that many of
    the schemes to pass keys from AP to AP exhibited. (Jesse,
    Aug 28)

2. Is the document going to be specific for 802.11?

    Tentative answer: 802.11i should only be used as an
    (Pasi, Aug 28)

    The document should not be 802.11 centric, but 802.11i
    is one very good test case for it, both because it is
    becoming widely deployed, and because it makes different
    enough assumptions from some of the other architectures
    to exhibit different issues. (Jesse, Aug 28)

NAMING

1. Should EAP SAs and link layer SAs be named?

    Tentative answer: Yes. (Jesse, Russ, Bernard at
    IETF-57)

2. How should the SAs be named?

    Tentative answer: through the identifiers and
    nonces exchanged.

SCOPE, ENFORCEMENT

1. Can an EAP SA have multi-machine scope?

    Tentative answer: I would say that it can't have multi-machine
    scope. However, I'd suggest that the way to avoid this is to
    say so explicitly -- "The peer MUST NOT provide keys
    produced by EAP methods to a third party." (Bernard,
    Aug 28)

    I don't think an EAP SA can have multi-machine scope, because
    when a symmetric key crosses machine (or even address space)
    boundaries, it has to be considered compromised without very
    special assumptions that are apparent to the (lower case) peer.
    (Jesse, Aug 28)

2. Can a peer do an EAP authentication on one port (Calling-Station-Id),
    then move to another authenticator and do a "fast resume"
    on another port (different Calling-Station-Id)?

    Tentative answer: This is the same problem we have been discussing
    in other guises. When the Peer can determine that the "different"
    ports are on the "same" machine, then this should be allowed.
    (Jesse, Aug 28)

3. Can a NAS with multiple Called-Station-Ids share AAA-keys
    between ports with different Called-Station-Ids? For
    example, can an EAP peer call in on one Called-Station-Id,
    then call back on another one, demonstrate knowledge of the
    AAA-Key and continue where it left off?

    Tentative answer: The problem with this is the peer cannot
    distinguish this situation from a case where the key has been
    compromised. While it is desirable, we need some way to bind
    the same NAS identifier onto all of its interfaces, and then
    find some way to securely convey this information to the peer.
    (Jesse, Aug 28)

4. What is the scope of the AAA Key sent from the home
    server to the access point?

    Tentative answer: Called-Station-Id and Calling-
    Station-Id included in the AAA Request (Bernard,
    Aug 28)

5. Once we decide what the scope of the AAA-Key is, the next question
    is "do we enforce this scope?"

    Putting MSK into the AAA-Key doesn't "bind" it to the endpoint
    identifiers.

    Computing the AAA-Key from a hash of the MSK and the scope identifiers
    would accomplish this.  Doing this would require that the EAP
    peer, the authenticator and the AAA server all agree on the endpoint identifiers
    of the EAP peer and authenticator. It would also require
    changes to the currently used AAA Key Attributes (e.g. RFC 2548).

    For example, if we use Called-Station-Id and Calling-Station-Id (e.g.
    AP MAC address and STA MAC address) as the identifiers,
    and we "bind" the AAA-Key to those identifiers by using them in the
    computation of the AAA-Key,  then if the AP were to broadcast a
    different BSSID to the station than it uses in the Called-Station-Id
    sent to the authentication server, then the AAA-Key the AP obtains
    from the AAA-server would not agree with the key computed by the
    station.  Similarly, the AP could not lie about the station's identity
    by sending a forged Calling-Station-Id to the authentication server.
    Of course, doing this would require changes to AAA key attributes.

    For example: AAA-Key = PRF (MSK or EMSK, EAP peer id, EAP auth id)
    (Bernard, Aug 28)

6. How are the authorizations given for the user
    related to the AAA Key?

    Tentative answer: The AAA-Key SA includes all the
    authorizations included in the AAA Accept message
    (Bernard, Aug 28)

    [Not sure I understand what "SA includes" technically
    means. Does it mean that the AP remembers the particular
    authorization, even if there was a fast handoff or
    similar? But the AP is trusted to honor these?]

7. One point to clarify is whether the Called-Station-Id
    includes the SSID for this purpose.

    Tentative answer: My recommendation would be that it not
    include the SSID. This would imply that a AAA-Key could be
    used within the NAS for any SSID, as long as the
    Called-Station-Id does not change. (Bernard, Aug 28)

    This is how I think about this issue as well, but numerous
    commenters on the 802.11i D5.0 letter ballot disagree. I do
    not understand their position yet, so it is probably
    premature to close this issue. (Jesse, Aug 28)

BACKWARDS COMPATIBILITY

1. Will the new design with scoping etc. be backwards
    compatible with WPA and other uses of EAP where keys
    are derived?

    Tentative answer: Not fully. If the AAA Keys are
    different in the new scheme, the access point will
    use a different key than an old peer expects. On the
    other hand, we can negotiate support for this, so
    backwards compatibility can be retained (but see next
    question). (Jari, Aug 30)

2. Will there be bidding down attacks based on the above?

    Tentative answer: Yes. For an old client, the AP needs
    the MSK, and can't use the scoped MSK. (Jari, Aug 30)

    But if the AP includes a "I-support-
    scoped-keys" bit (or something) in the RSN IE (Beacon
    frame), then an MitM attacker can't downgrade it, since
    the RSN IE is already protected in WPA. Additional
    attacks from a compromised AP can be avoid if the
    scoped AAA key is derived from EMSK instead of MSK.
    (Pasi, Aug 31)

--Jari

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Joseph Salowey" <[email-masked]>
Date: Fri, 5 Sep 2003 13:33:08 -0700

I'm a bit confused by the terminology, especially EAP SA and AAA-key
comments in line.

Joe

>     special assumptions that are apparent to the (lower case) peer.

[Joe] Can you define an EAP SA?  In the case where an EAP-Server/AAA
server is involved there is an SA derived between the EAP-Peer and the
EAP-Server, is this the SA.  Keys derived from this SA are at least
distributed to one other party (this might be a sun-SA).  This is
already a multi-machine scope.  So I'm not quite sure what is meant by
EAP SA.  I think one difficulty here is that in general EAP is defined
transparent to the existence of a AAA.  When you intorduce keying
security then it is hard to hide these architectural differences.

>     ports are on the "same" machine, then this should be allowed.

[Joe] Hmmm... Is authenticaiton identitical to establishing an SA or are
they two different (but related) things.

>     find some way to securely convey this information to the peer.
[Joe] Can we also define what AAA Key is?  Is it a master key held by
AAA? Is it a key transmitted from AAA to AP?