Artur Hecker wrote:

Hi Arran

In my eyes, the fact that it is not confirmed is a minor issue. It's probably a reasonable design choice: as you said, the controlled port at the Auth may be in the authorized state, while the client might think that is unauthorized, so what? This can happen at any time anyway, e.g. in wireless when the connection suddenly drops. Besides, in practice most Supplicants won't bother sending anything at all: what if the NIC was suddenly unplugged by the user? What if the PC has crashed? What if it was unpowered, etc etc etc. Agreed. I guess I was looking at it more in terms of integration. It's more about the supplicant knowing when it's state has been reflected by the authenticator. This is done when the supplicant authenticates, the EAP-Success is confirmation that the Authenticator PAE is in the authorised state. But not when the supplicant forcefully disconnects with an EAPOL-Logoff.

In any case, confirmed or not, every Authenticator *must* be prepared for such a situation. By the way, it is in no way against its policy, since it is not up to the supplicant (=client) to decide when the network access port is to be opened and when it is to be closed. This decision is up to the AuthServer, which has supposedly issued a positive decision as to the controlled port in question being open at this very moment. These differences in PAE state can cause issues when attempting to use the supplicant PAE state to control the state of other 'Zero-Configuration' networking clients like DHCP. If the EAPOL Logoff message were confirmed by the Authenticator, this could be a used trigger DHCP lease acquisition. The IEEE 802.1x 2004 document does mention DHCP integration briefly, which is why I'm surprised they didn't think to provision for it here.

Actually I would rather complain about other issues with EAP-Logoff. For instance, it is not authenticated/signed, so it is a perfect DDoS possibility.

Not really. The only situation in which I could see EAP-Logoff being used as a DDoS attack is in a shared media wired LAN, and not many people implement shared media wired LANs with dot1x authentication... it's also fairly hard to tap a wired LAN between the supplicant and the NAS without someone noticing. Unless a wireless AP would accept unencrypted packets from a station *after* the WPA four way handshake had been completed; i'm not really familiar enough with 802.11 to know... Thanks for your input Artur. Arran

Artur

On 29 Apr 2008, at 18:50, Arran Cudbard-Bell wrote:

...

Arran Cudbard-Bell wrote:

...

Hi,

Having some interesting issues with a HP ProCurve 2510 an Apple Mac Power Book running OSX 10.5.2, and MAC-Auth + EAP-Auth on the same wired port.

I know this isn't strictly the list for this as this isn't really RADIUS, but i'm not sure where to post...

Two questions:

IEE802.1x-2004 8.1.3 EAPOL-Logoff When a Supplicant wishes the Authenticator PAE to perform a logoff (i.e., to set the controlled Port state to unauthorized), the Supplicant PAE originates an EAPOL-Logoff message (see 7.5.4) to the Authenticator PAE. As a result, the Authenticator PAE immediately places the controlled Port in the unauthorized state

1) It appears in the spec that there is no requirement or indeed method of the Supplicant PAE of confirming that the EAPOL-Logoff has been honoured. So the supplicant PAE could be in the unauthorised state while the Authenticator could be in the authorised state. Is this an over site of the dot1x spec, or is this meant to be handled at a higher level with EAP ? Sorry. Looking at the diagrams in 8-5 it appears my suspicion is correct. Unless a re-auth timer is implemented by the Authenticator PAE, this mismatched authentication state could persist indefinitely.

The EAPOL-LOGOFF frame is *not* retransmitted to the Authentication server... and the Authenticator PAE does not respond to EAPOL-LOGOFF frames, it just alters it's state. So if the EAPOL-LOGOFF frame was lost in transit... damn, why no EAPOL-LOGOFF-CONFIRMATION packet ... In every other part of the EAP/dot1x spec a request *should* always be answered by a response... but not here... are these guys idiots, or am I being dense ?!

See this would solve the issue in question 2 perfectly.

-- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

-- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900

Artur Hecker wrote:

Imo, there are no dependencies between DHCP and dot1X.

That can be fixed. EAP methods can be leveraged to push keys to the client, which can sign the DHCP packet (RFC 3118). This also lets the client know it's talking to the correct DHCP server.

My personal perception is completely inverse to yours: I think that 802.1X is more used in wireless (WiFi) than in wired LANs. But maybe you have some statistics on that? That would be interesting to know :-)

A lot of people are starting to look into 802.1X for wired LANs. It can help satisfy regulatory issues in some countries... Alan DeKok.

Artur Hecker wrote:

Yes, as I said, the dependency in that sense might make sense. We did it in a student project, and I rather see the problem at the network side: the EAP-Server and the DHCP server almost never reside at the same machine

Really? They must be running bad software. :) There's no reason that the EAP server && DHCP server can't be the same *binary*.

and typically are in different (logical) subnetworks (VLANs, etc.) Imo, no standard protocol exists designed to do such things.

There is interest.

Obviously, it is possible but a bit cumbersome in practice. One might ask oneself if it makes sense.

The answer is: Yes.

:-) These days, if you do not have access control, people look at you like you were an alien. However, everybody agrees that the security problems come once you let people in... and NAC is mostly nonsense.

I agree. Hence the need for a real DHCP server that is integrated with the rest of your access control. Alan DeKok.

Artur Hecker wrote:

But the reason for this is the following. In the current best practice, the EAP-Server must never be reachable for clients, while the DHCP server *must* be reachable from client by definition. I.e. only access controllers (part of your infrastructure) speak to the EAP-Server, while your clients speak to the DHCP server.

Yes. That simplifies security a little.

That said, I agree with the underlying strategy. I would have loved to see DHCP integrated with 802.1X from the very beginning. Actually, I would have gone farther and rather proposed a virtual and generic signaling protocol for the session opening, where a client can negotiate all kinds of options with the network on all layers at the same time. This can be easily done with TLV, etc. Then, a provisioning server could not only open the access but also preprovision the client with IP config, proxies to use, existing printers, available servers (SMTP, shares, etc.) etc etc etc, even before it gets IP layer access. That would have been very nice for an enterprise integration. But well.

That's called EAP-TTLS, with extra stuff inside of the tunnel. :) Alan DeKok.

Hi

...

...

That said, I agree with the underlying strategy. I would have loved to see DHCP integrated with 802.1X from the very beginning. Actually, I would have gone farther and rather proposed a virtual and generic signaling protocol for the session opening, where a client can negotiate all kinds of options with the network on all layers at the same time. This can be easily done with TLV, etc. Then, a provisioning server could not only open the access but also preprovision the client with IP config, proxies to use, existing printers, available servers (SMTP, shares, etc.) etc etc etc, even before it gets IP layer access. That would have been very nice for an enterprise integration. But well.

That's called EAP-TTLS, with extra stuff inside of the tunnel. :)

What's the deal with chaining EAP Methods inside an EAP TTLS tunnel.... could you run EAP-MSCHAPv2 - EAP-TNC - EAP-DHCP (Fictitious EAP type) inside the same tunnel ?

Authentication - NAC - Configuration :)

That's what I meant. You could actually map this to a virtual interface (a signaling channel) and put the whole mobility things, network and service discovery, etc. on it: handoffs, mDNS, UPnP, whatever, to discover where you are and what it is. All that signed / encrypted with the authentication keys, previously established. Fine for an enterprise and technically this is not a problem. But it is not wanted, for two reasons: 1. The IETF's EAP-WG does not want it. EAP is authentication, not a generic transport. You could come up with something simular and standardize it through IEEE and IETF, ok. but there is problem nr 2: 2. Even if it is ok for an Enterprise network, it is not ok for the Internet, which IETF is responsible for. It means indeed a different access model. The local provider becomes a bit too mighty in this configuration, so it cannot become a generic standard. This has been recently discussed at HOKEY, I believe. artur

Artur Hecker wrote:

hi

just one comment.

On 30 Apr 2008, at 10:59, Arran Cudbard-Bell wrote:

...

Artur Hecker wrote:

...

Hi Arran

In my eyes, the fact that it is not confirmed is a minor issue. It's probably a reasonable design choice: as you said, the controlled port at the Auth may be in the authorized state, while the client might think that is unauthorized, so what? This can happen at any time anyway, e.g. in wireless when the connection suddenly drops. Besides, in practice most Supplicants won't bother sending anything at all: what if the NIC was suddenly unplugged by the user? What if the PC has crashed? What if it was unpowered, etc etc etc. Agreed. I guess I was looking at it more in terms of integration. It's more about the supplicant knowing when it's state has been reflected by the authenticator. This is done when the supplicant authenticates, the EAP-Success is confirmation that the Authenticator PAE is in the authorised state. But not when the supplicant forcefully disconnects with an EAPOL-Logoff.

well, there is a big difference: the EAP-Success (unsigned, *sigh*) is the confirmation necessary for supplicant to know if it proceeds or not (DHCP, data comm, etc). (By the way, it's difficult to compare: the EAP-Success is EAP, while EAPOL is dot1X). The EAPOL-Logoff is not necessary for anything. You send it before you stop communicating. You might just as well just stop communicating. Not true. From an accounting point of view the EAPOL-Logoff is pretty vital to maintain accurate information about which users are on which stations on which layer 2 network where. Sure a change in state at the MAC level will terminate any active sessions on that port, but a change in state at the MAC level doesn't always occur.

I know RADIUS Accounting isn't related to EAP authentication in any way, but nor is DHCP. At a protocol level there is no requirement for the supplicant to signal the authenticator telling it, that it wishes to end the session. But for all the other protocols that hang off it, it is vital to have reliable state information.

If you want to restart, you simply resend the EAPOL Start in either case. It changes nothing.

...

...

In any case, confirmed or not, every Authenticator *must* be prepared for such a situation. By the way, it is in no way against its policy, since it is not up to the supplicant (=client) to decide when the network access port is to be opened and when it is to be closed. This decision is up to the AuthServer, which has supposedly issued a positive decision as to the controlled port in question being open at this very moment. These differences in PAE state can cause issues when attempting to use the supplicant PAE state to control the state of other 'Zero-Configuration' networking clients like DHCP. If the EAPOL Logoff message were confirmed by the Authenticator, this could be a used trigger DHCP lease acquisition. The IEEE 802.1x 2004 document does mention DHCP integration briefly, which is why I'm surprised they didn't think to provision for it here.

Why? DHCP only depends on EAP-Success, but certainly not on EAP-Logoff. I think that I do not understand your issue: you cannot send ANY DHCP messages after EAP-Logoff has succeeded, it's too late. The controlled port at the L2 will be closed. DHCP is L3 data going over the controlled port. If you want to do any integration, you could drop your DHCP lease but *before* closing the controlled port. This is where it gets interesting. Just because the dot1x controlled port is in the closed state, it does not mean that another .1D bridge filter can't be open and allow traffic. HP et al have introduced (or are attempting) to introduce two tiered authentication, where the client is authenticated by MAC Address using RADIUS authentication, and then may 'Elevate' by sending an EAPOL-Start or Responding to an Ident Request. If the EAP session is terminated, with an EAP-Logoff then the client is Re-Authenticated with MAC-Based authentication.

I'm guessing this is implemented with two .1D bridge port entities operating on the same physical port, but i'm not sure.... 1. Physical connection to the port 2. Authenticated on MAC Using RADIUS - Mac Auth Session Starts 2a. MAC State change signals DHCP client 2b. DHCP Request 2c. Got DHCP Lease on MAC-Auth VLAN 3. Authenticated using dot1x - Mac Auth Session Ends - dot1x Session begins 3a. Supplicant signals DHCP client 3b. DHCP Request 3c. Got DHCP Lease on dot1x-Auth VLAN 4. EAP-Session Ends (EAPOL-Logoff) 4a. Supplicant signals DHCP client (too quickly) 4b. DHCP Request 4c. Got DHCP Lease on dot1x-Auth VLAN 5. Authenticated on MAC Using RADIUS - Mac Auth Session Starts 5a. DHCP client satisfied at 4c, station now bogon on MAC-Auth VLAN 6 Physical Disconnection - Mac Auth Session ends See the problem is at 4a, the DHCP client has no way of knowing when the Authenticator has honoured the EAP Session termination, and so has no way of knowing when the EAPOL-Logoff was actually honoured.

Imo, there are no dependencies between DHCP and dot1X. And if they exist, they follow the other sense: DHCP is transported by the L2 channel opened by dot1X. So, you need to open the session before starting DHCP and you might want to terminate DHCP leases etc. before sending Logoff (even it this seems completely unnecessary, it will expire anyway). In any case, I do not see why Logoff needs to be confirmed, sorry.

See above.

...

...

Actually I would rather complain about other issues with EAP-Logoff. For instance, it is not authenticated/signed, so it is a perfect DDoS possibility.

Not really. The only situation in which I could see EAP-Logoff being used as a DDoS attack is in a shared media wired LAN, and not many people implement shared media wired LANs with dot1x authentication... it's also fairly hard to tap a wired LAN between the supplicant and the NAS without someone noticing.

Oops? If you ask me, the 802.1X/EAP were actually pushed and promoted to improve WiFi security, even if they have nothing to do with WiFi. WPA, WPA2/802.11i (i.e. both Enterprise and PSK) use EAPOL and are based on 802.1X (at least in part). All newer recommendations concerning WiFi security mention 802.1X access control and EAP for session opening. HOKEY, 802.11r etc. work on that too, etc.

By the way, Ethernet *is* a shared medium. So, unless you have a completely switched wired LAN, you can always send EAP-Logoff (presumably with the wrong source MAC address) to anybody on your trunk. Even in switched LANs, depending on the architecture, there are possibilities to trick out the switches with poisoning, broadcasts, etc. EAP-Logoff should have been signed, at least optionally, especially if key material exists... We do have a completely switched wired LAN. One to One links from the edge switches to the clients, switched all the way to the core... Unless I misunderstood what you meant be switched.

You can't broadcast EAPOL Logoff packets, if you do, they will be ignored.... 7.5.7 Validation of received EAPOL MPDUs and EAPOL protocol version handling A PAE shall process a received EAPOL MPDU as specified in this clause if and only if the following conditions are all true: a) The Destination MAC address field contains the PAE group address, as specified in 7.8 (in non- shared media LANs), or the specific MAC address of the PAE (in shared media LANs). b) The PAE Ethernet Type field contains the value of the PAE Ethernet Type, as specified in 7.8. c) The Packet Type field contains one of the values EAP-Packet, EAPOL-Start, EAPOL-Logoff, or EAPOL-Key, as specified in 7.5.4. I think A is the important one there .... In a shared media wired LAN, you can spoof the source MAC, and send an EAPOL-Logoff to terminate another clients session on your physical LAN segment. So yes, validation with keying material would be useful here... however not all EAP types generate keying material... Poisoning is an interesting one but I don't think that's possible either. I don't see how you could spoof EAPOL-Logoff packets in an encrypted wireless medium, unless you'd already cracked the WPA keys... You'd need to crack the unicast key for the target client....

My personal perception is completely inverse to yours: I think that 802.1X is more used in wireless (WiFi) than in wired LANs. But maybe you have some statistics on that? That would be interesting to know :-)

We have 3500 dot1x authenticated wired ports, and all of 11 wireless access points running dot1x authentication... I've also found dot1x to work far more reliably on a wired medium than wireless, and after talking to others at Networkshop (Big networking conference) that is the general consensus.

...

Thanks for your input Artur.

Discussing standars is fun :-)

That is is

Thanks artur

Thanks, Arran

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

-- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900

Artur Hecker wrote:

Hi Arran

...

...

well, there is a big difference: the EAP-Success (unsigned, *sigh*) is the confirmation necessary for supplicant to know if it proceeds or not (DHCP, data comm, etc). (By the way, it's difficult to compare: the EAP-Success is EAP, while EAPOL is dot1X). The EAPOL-Logoff is not necessary for anything. You send it before you stop communicating. You might just as well just stop communicating. Not true. From an accounting point of view the EAPOL-Logoff is pretty vital to maintain accurate information about which users are on which stations on which layer 2 network where. Sure a change in state at the MAC level will terminate any active sessions on that port, but a change in state at the MAC level doesn't always occur.

I know RADIUS Accounting isn't related to EAP authentication in any way, but nor is DHCP. At a protocol level there is no requirement for the supplicant to signal the authenticator telling it, that it wishes to end the session. But for all the other protocols that hang off it, it is vital to have reliable state information.

Ok, accounting is a very different issue. You were talking about DHCP before, so I did not get it. It's all part of the same problem.

Actually, you speak about Accounting control: you want to be sure that the EAP-Logoff has been taken into account by the access controller and that presumably your access is not billed anymore. From my experience, this depends a lot on your billing plans, tariffs, models, etc. And precise per minute or byte accounting works rather badly with Radius... As you said, it is a completely different problem anyway.

By the way, in that situation, EAP-Logoff would need to be signed. Just as any reply...

...

This is where it gets interesting. Just because the dot1x controlled port is in the closed state, it does not mean that another .1D bridge filter can't be open and allow traffic. HP et al have introduced (or are attempting) to introduce two tiered authentication, where the client is authenticated by MAC Address using RADIUS authentication, and then may 'Elevate' by sending an EAPOL-Start or Responding to an Ident Request. If the EAP session is terminated, with an EAP-Logoff then the client is Re-Authenticated with MAC-Based authentication.

Ok, this is something else once again. However, imo this is a very different problem. This is the integration of two tiers of a multi-tier access control. This cannot be within the scope of the standardization of any single access control type used here.

It is therefore up to the manufacturer to make sure that his solution is feasible, reliable and that it works. Just one other word: especially in multi-tier environment, there should be a precise distinction of different EAPOL packets. Thus, especially in this environment the signing of EAP-Logoff seems vital. Otherwise the outer tier could always send you a spoofed confirmation even though it never gave your Logoff to the inner tier, etc.

Anyway, it's a very different problem, out of scope of dot1X. What scope does this fall within ?!

...

...

...

...

Oops? If you ask me, the 802.1X/EAP were actually pushed and promoted to improve WiFi security, even if they have nothing to do with WiFi. WPA, WPA2/802.11i (i.e. both Enterprise and PSK) use EAPOL and are based on 802.1X (at least in part). All newer recommendations concerning WiFi security mention 802.1X access control and EAP for session opening. HOKEY, 802.11r etc. work on that too, etc.

By the way, Ethernet *is* a shared medium. So, unless you have a completely switched wired LAN, you can always send EAP-Logoff (presumably with the wrong source MAC address) to anybody on your trunk. Even in switched LANs, depending on the architecture, there are possibilities to trick out the switches with poisoning, broadcasts, etc. EAP-Logoff should have been signed, at least optionally, especially if key material exists... We do have a completely switched wired LAN. One to One links from the edge switches to the clients, switched all the way to the core... Unless I misunderstood what you meant be switched.

ok.

...

You can't broadcast EAPOL Logoff packets, if you do, they will be ignored....

I didn't mean that you'd broadcast the EAPOL packet. You broadcast something under a wrong source MAC until some switch starts forwarding packets for this address to you. Then you can safely send out EAP-Logoff packets to the switch on the user's behalf, resulting in the closure of this session (this is DDoS). It does depend on the precise architecture though, e.g. where is the controller, is the first switch the access controller etc. It does not always work. Surely the there's a different Authenticator instance for each physical port, so a logoff received by one Authenticator instance would not be honoured if it could not find a session matching the source Mac existing on that instance.

...

I don't see how you could spoof EAPOL-Logoff packets in an encrypted wireless medium, unless you'd already cracked the WPA keys... You'd need to crack the unicast key for the target client....

Stop - the EAPOL packets are neither signed NOR encrypted, in any medium.

That's the whole problem I'm talking about. They are *not* data traffic, these are management frames, as defined by 802.1X (1 = management). They never go through TKIP, CCMP, WEP etc. Since MAC addresses cannot be encrypted neither by definition, you can safely take the source address of the user and send EAPOL Logoff on his behalf.

Woha, I didn't realise that ! Ok yes this could be a big issue.

artur

...

...

My personal perception is completely inverse to yours: I think that 802.1X is more used in wireless (WiFi) than in wired LANs. But maybe you have some statistics on that? That would be interesting to know :-)

We have 3500 dot1x authenticated wired ports, and all of 11 wireless access points running dot1x authentication... I've also found dot1x to work far more reliably on a wired medium than wireless, and after talking to others at Networkshop (Big networking conference) that is the general consensus.

...

...

Thanks for your input Artur.

Discussing standars is fun :-)

That is is

...

Thanks artur

Thanks, Arran

...

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

-- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

-- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900