eap Mailing List: (fwd) notes from the keying framework design team call

[Jari Arkko (jari.arkko]

Notes from the first meeting of the EAP keying framework design team,
September 4th, 2003.

Participants: Bernard Aboba, Jesse Walker, Jari Arkko, Bob Moskowitz,
Uri Blumenthal, Pasi Eronen, Dave Nelson (and two others, did not
catch who -Jari)

Notes: Jesse Walker

ADMINISTRATIVE
==============

1. We will arrange a conference call every week with the same number
   and passcode.

2. Deadline: One deadline is the proposed joint meeting Oct 15 in
   Herndon. Need to issue new document version to resolve issues. Need
   progress in next three weeks to make this feasible.

3. Questions on practicalities. Henrik Levkowetz will be the editor
   also for the keying framework document.

TECHNICAL DISCUSSION
====================

What are implications of scope enforcement?

Jesse: If we want to enforce scope, do we need to publish the NAS
identity in the EAP/Request-Identity. We can only enforce using
authenticated identities

Uri: Concur

Bernard: Important to under that EAP authentication is not done every
time. If not being used and need the functionality, then we need to
put it somewhere else.

Uri: There is an issue overlooked. EAP used to be a two-party
protocol, but later RADIUS was introduced to make it a 3-party
protocol.

Bob M: EAP is still a 2-party protocol.

Jesse: Yes. Keying is a 3-party protocol.

Bob: But this is a 4-party protocol.

Jesse: What is the 4th party?

Bob: Assume supplicant owns its authentication capability.

Uri: don't consider things like CA fourth party.

Jari: The next AP could be a 4th party.

Jesse: But its still 3 parties at a time.

Bob: Two bridges authenticating over some media, and how the two
bridges form the authentication. Each has its own authentication
server.

Jesse: If 802.1X wants to solve that problem, let them, because we
already know we won't understand what we are doing. Don't want to work
on unsolvable problems.

Uri: Want to limit it to 3-party. One party has to know the identity
of the other two. NAS identity: what is it?

Pasi: each party must have an identity. But a client may not be able
to distinguish identity from random bit string.

Jesse: The requirement is the EAP server asserts that the identity of
the party the EAP peer is talking to is an authenticated identity.

Bernard: The issue is there is no binding between the different
identifiers. If your proxy does not check, the EAP messages can be
laundered.

Uri: Right. That is why one needs authenticated identities.

Bernard: But is authenticated if the proxy checks.

Uri: When there are hundreds of APs, chance of one compromised is very
high.

Bernard: Not outlandish to assume an access point is compromised.

Uri: Right. APs must therefore have an identity known to the EAP
server, so it can verify the identity.

Bernard: Many identity attributes sent to the RADIUS server. There may
or may not be that binding on the RADIUS server. If the AP's identity
is an FQDN, then RADIUS server can do a reverse lookup, but it doesn't
have to be FQDN. Saying NAS must assert the same name.

Jesse: The NAS and RADIUS server must set up their own authenticated
session to solve this problem.

Bernard: Something like this is done today. Need binding of IP address
to NAS id.

Jari: Three identities: NAS identifier, called station id, and NAS IP
address. Must link all of them.

Jesse: Well, we can declare RADIUS server must do this or it is not
secure.

Bernard: We can say that right attributes have to be sent.

Uri: What do we do with NAS Identity? Having an octet string good
enough? Or do we need an FQDN?

Pasi: If some party authenticates this identity, then it doesn't help
unless octet string is meaningful. Must check that it is the "right"
string that is used by authentication.

Bernard: If just a string, can be configured automatically. But some
sort of manual entry required. Need same name in RADIUS server.

Jari: Why are we talking about NAS identifier? Why not called station
id?

Bernard: This makes a difference. Let's go through scenarios. What
scenarios to enable?

Question1: AAA server gives key to an AP. It can have multiple SSIDs
and BSSIDs. Similarly, NAS can have multiple phone number. If a STA
has associated with one port on a distributed AP, is it ok to use same
key on more than one port?

Jesse: only if the client is convinced that the key is being used by
the same entity.

Pasi: Agree.

Bernard: Virtual AP are designed to make it same physical AP looks
like multiple APs.

Jesse: If client can distinguish, then it's ok.

Bernard: So do a "fast hand-off" across different domain.

Jesse: It is not clear that hand-off across domains without
authenticating to new domain has anything to do with security.

Bernard: The implication is the logical identity has to be part of
answer. NAS identity is not enough.

Jesse: Right, but that doesn't mean the physical part won't be part of
the solution.

Bernard: Jesse's opinion is that crossing boundaries without
authentication is not good, so using key across administrative
boundaries is no good. So this seems to be a problem. Within an
administrative domain, and I have a guest and corporate VLAN from the
same SSID. Authenticate, fast-handoff from guest to corporate VLAN? It
might be ok if context came down with key. This would prevent
elevation of privilege, as long as the context didn't change. The
problem in the multi-domain case was money could flow if used wrong
context. If I authenticate on corp net and doing charge-back, but
guest has no charging. Move to guest, then can theft of service. So
context not sufficient.

Pasi: How do you know user can access this or that VLAN?

Uri: how is this access going to be decided?

Bernard: There are access points that implement different
VLANs. People do this today.

Uri: The AP decides access?

Bernard: No, they go back to the RADIUS server. Defining key scope
will determine whether one can do hand-off.

Bob: You have to control the domain of applicability of key if you
hand off context. Since the group key is controlled by BSSID, you
can't have one BSSID supporting multiple SSID with 802.11i.

Bernard: You will have leakage in other cases, too.

Dave N: What is the case?

Bernard: It can be an elevation of privilege to go from one VLAN to
another.

Pasi: If you switch and all context transfers, then won't the behavior
be the same?

Bernard: Seems so.

Pasi: But client would think it is on guest...

Bernard: But accounting would be the same.

Jari: But if everything is the same, then why bother?

Dave N: If everything the same when moving between differentiated
services, then why doing it? Do you need a separate SSID?

Bernard: The guest network might be open, and corporate net not. So
are saying if you bring ALL context, then reuse is ok.

Pasi: But pointless. Why not keep using the corp account and not move?

Jesse: I think there is still a security problem, because distributed
state is no longer synchronized.

Dave: Provisioning single BSSID with two SSIDs will lead to these
problems.

Bernard: Some RADIUS servers send list of authorized SSIDs. If the
authorizations conflict with the SSID the client tries to use, then
the AP can block it. Not clear this is useful.

Next one: station with multiple ports: Hand-off to another port?

Pasi: Same logic applies: if client can be convinced it is two ports
on same entity, ok, otherwise not.

Dave: Once you start talking about multiple user systems, this breaks
apart.

Bernard: Definition of "entity" is hard.

Pasi: We can't enforce any definition of entity with the protocol.

Bernard: AP has same problem. there are designs of distributed
APs. Everything looks the same in all of these cases. What about
cluster design?

Jari: Pasi said in the AP case only the AAA server can assert
something is one entity? Why is this?

Jesse: Only AAA server is in a position to make assertion the client
can believe.

Jari: But if the AP is compromised, won't you see both the session
keys and AAA keys, and therefore the attacker can appear as the
legitimate node even towards the AAA.

Jesse: Yes, but there are different ways the keys can get compromised,
different attacks. Some attacks might just reveal the session keys,
not the AAA keys.

Bernard: There are assumptions about hygine that go into this. The
administrator is trying to prevent you from doing unauthorized
things. "Don't tell your password to everyone." I have 3 laptops with
their own certificates, but I use same password on each.

Clint: The discussion of how to limit where a key goes. There could be
a rogue AP that mimics the real AP by using the same BSSID.

Bernard: You can do some things to solve it. If I get complete control
over AP, there are obstacles to impersonating other APs.

Uri: But there might be trust relations.

Bernard: One of the requirements is if one AP is compromised then we
don't compromise keys on any other AP. If I move the AP address, then
shared secret won't work. I can change BSSID, but if proxy is checking
this, get caught. The binding will stop it.

Pasi: Agree this is possible. But making tradeoff. Fast-handoffs that
don't involve AAA server is no longer possible.

Bernard: Disagree. Look at Bill Arbaugh's or Bob Moskowitz.

Pasi: Ok, but each AP must get key from AAA server.

Bob: Not true. Doesn't work this way in my scheme.

Bernard: We've described several cases. People are willing to be
liberal about handoff as long as you can authenticate things. Propose
have some position papers.

Jesse: You've asked us to contribute position papers about scenarios
enabled and what the issues are in.

Bernard: Yes.

Volunteers: Dave N: context transfer; Clint: PMK sharing; Bernard will
try to write one, too.