Provide Feedback on this Broadcast

Note This document is based on the original spoken Support WebCast transcript. It has been edited for clarity.

Jeff Baziuk: My name's Jeff Baziuk and today I will be talking about the 802.1x authentication client in Microsoft® Windows®.

Here are our objectives (slide 2): In the year 2000, IEEE created the 802.1x specification. This was done to further protect wired and wireless networks. And Windows supports this specification in Windows XP Service Pack 1 and in Windows Server™ 2003. Today, I'm going to provide some detailed information on 802.1x, how we (as Microsoft) implement the 802.1x protocol, and then I want to discuss best practices in how to configure the 802.1x client in Windows.

Here is our agenda (slide 3). First of all, I want to lay the groundwork of what 802.1x authentication really is, and how it enhances network security. We'll talk briefly about the specifics of the protocol, and we'll also get into implementation and EAP methods (Extensible Authentication Protocol methods). And then we'll talk about the kind of configuration and the type of scenarios that you'll be using 802.1x in.

First of all (slide 4), 802.1x authentication is a port-based access control mechanism. And I'll get to this idea more on the next slide. But basically, this type of authentication works on any kind of network, wired or wireless. Both on wired and wireless, you still have the idea of port-based access control. 802.1x also enables dynamic key management for wireless networks and you're able to use EAP.

Let's just look at a typical topology (slide 5) and let's concentrate on the uncontrolled port versus the controlled port. Now, our client computer (also called the supplicant in 802.1x terminology) is trying to access network resources. To do so, we use an end-to-end EAP connection. This obviously needs to go through the access point to actually access the network, or switch, if we are dealing with a wired network.

Initially, when the client tries to get onto the network, he gains access through the uncontrolled port. All 802.1x authentication packets initially go through the uncontrolled port. Then once the client's identity is verified and authentication is complete, then access to the network is granted through the controlled port. Again, the idea of an open door initially leading to only one place, which is the RADIUS server, versus an open door to the network later, once authentication occurs. This provides another level of security for both wireless and wired networks, not just physical access, but then also access gained through authentication through a controlled port. Let's take a look at step-by-step connections.

First of all, we begin by connecting to the authenticator (slide 6). In this case, we'll consider that an access point or AP, using 802.11 association. And at first, that access is blocked. Then an EAPOL-Start message is sent from the client or supplicant to the AP. And once that occurs, a request identity is sent from the access point to the supplicant. The response identity occurs and this is all to verify the identity of the actual client machine and user. Once an identity is sent, then a RADIUS message is sent to the authentication server (RADIUS-Access-Request sent) and then a challenge request is sent back in the form of an EAP-Request to the supplicant. From here, an EAP-Response is sent with credentials. This is how the client is letting the authentication server know who the client is. You have a RADIUS-Access-Request here going to the authentication server; and then an accept, obviously, if credentials are valid, and then EAP-Success. Lastly, if we're dealing with certificate-based authentication, such as EAP-TLS, we're going to send an EAPOL-Key message, and then access will be allowed onto the network.

So how do we implement this protocol in Windows (slide 7)? First of all, we implement this protocol on wired interfaces by default, so it's always on. And it's usually something that is on and not known by the general user, but we turn this on by default.

With a wireless interface, however, it's integrated with the wireless configuration client. It's enabled by default if privacy is enabled. But if privacy is not enabled or a static key is set, then we turn off 802.1x. Also, dynamic key enforcement is also used. So if a key isn't sent after a connection succeeds, we wait five seconds and, if a key isn't sent at that time, then the connection is broken.

Lastly, we implement 802.1x with user and computer authentication enabled as default. We'll get into that more here.

First of all, when a machine starts up, we have machine credentials available, and we'll use those machine credentials and perform authentication (slide 8). Now, depending on whether or not a machine authentication fails or machine authentication succeeds, once a user logs on, we'll use user credentials, and that's when user credentials are obviously available. Based on whether or not user authentication succeeds, we have access to the network here. And then this process all happens over again when a user logs off or when you turn off your machine and go to restart it again.

It should be noted that in this slide, we're looking at the default authentication behavior in Windows XP SP 1 and Windows Server 2003. In our initial release of Windows XP, user authentication only occurred when the machine auth failed.

Okay, so this is our general configuration page (slide 9). When you look at an interface, such as the Local Area Connection Properties page, you're going to see that 802.1x is enabled by default. And on this configuration page, you're going to have some options. You can provide control over computer auth or guest auth, and you can actually select what kind of EAP method that you'd like to use by clicking on the EAP type drop-down list. In this case, what we're looking at here is smart card or certificate authentication using TLS or Transport Layer Security.

So, EAP or Extensible Authentication Protocol (slide 10). I wanted to show this slide because I wanted to make the differentiation between EAP as the EAP layer, and the authentication methods that are used in the method layer. We have three authentication types in the method layer that we use and that we implement in Windows. We have TLS, as I mentioned before, we have MD5, and we have PEAP with two various methods (MSCHAPv2 and TLS). EAP is a method to package different auth methods and the method layer provides the security. EAP by itself provides no security. That's an important thing to note.

Let's talk about EAP methods available in Windows (slide 11). As I mentioned before, we have three types: EAP-TLS, PEAP, and EAP MD5. EAP-TLS, or EAP using certificates, is the default setting for 802.1x client in Windows. PEAP (Protected EAP) allows the two inner-methods that I mentioned: we have TLS or cert-based and we also have MSCHAPv2, or password-based authentication. Thirdly, we have EAP-MD5. This is just more of a proof of concept authentication protocol. This doesn't provide mutual authentication and it's password-based. It transfers passwords in the clear and it doesn't provide an encrypted session between the supplicant and authenticator. So we're going to concentrate and talk about EAP-TLS and PEAP in the next slides.

Okay, here are the various EAP methods (slide 12). When you click the drop-down list, you'll see, here to the left, there's a wired interface properties pane (Local Area Connection Properties page). And it has MD5, PEAP, and EAP-TLS. And here, as you notice on the Wireless network properties page, we have PEAP and EAP-TLS. This slide is just to show that on a wired network, you have MD5 as an available option, whereas on wireless, we do not allow that option.

EAP-TLS, as I mentioned before, uses both user and computer certificates (slide 13). You can obtain user and computer certificates a number of ways. You can obtain them through auto-enrollment, through Web enrollment, through certificate import, or you can manually request certificates using the snap-in. Local computer store certificates are always available, but the only time that the current user certificates are available is obviously when a user logs on.

This is the configuration page of EAP-TLS (slide 14). I wanted to note just a couple of things here. Mutual authentication is enabled by default. This is denoted by this check box here, the Validate server certificate check box. As we mentioned before during 802.1x, when the challenge request is sent from the RADIUS server that is when the server certificate is also sent. And if this button is selected on the client, Validate server certificate, we actually verify the certificate that's being sent over from the server. We actually verify the identity of the server that we're connecting to. Mutual authentication is very nice because normally in a network setting, we're interested in enhancing security of clients getting on to the network, so we want to make sure that the network that people are trying to get on to is secure. But in this case with mutual authentication, we're looking at protecting client machines as well. We wouldn't want to connect to a server that's not actually the server that we're trying to connect to. And with validating the server certificate, we can, again, verify the identity of the network that we're trying to connect to.

We also use the idea of a simple certificate selection, here. With this (the Use simple certificate selection check box) checked, we actually automatically select the cert that pertains to the network we're trying to connect to and then we connect, so that users do not have to actually select the cert themselves. If that is actually turned off, then you'll be prompted to select the cert for the network that you're trying to join.

Okay, now, you can also use EAP-TLS with smart cards (slide 15). I just mentioned EAP-TLS with machine- and user-based certificates. Another way to use EAP is with smart cards. In this case, when you use a smart card, you have a smart card reader that you insert a smart card into, and then you must enter a PIN to access a certificate on the smart card. In this case, the user certificate is actually put onto the smart card, instead of onto the machine itself. PIN input is not required again on subsequent re-authentication tries, so you are not going to be prompted over and over to reenter a PIN. It's only during the initial authentication that a PIN is required to be entered. When roaming out of range or back in range, you'll be prompted again. So when you have to do a full authentication, that's when you'll be prompted again for a PIN.

The reason why people use smart cards instead of user-based certificates is because at times, managing certificate stores on local hard drives can be difficult, especially if you have multiple users per machine. To minimize this and also to add a layer of enhanced security, people will carry around an actual smart card with their certificate on it and obviously, a PIN that they must enter to access that certificate.

Another method (slide 16) to consider is PEAP-MSCHATv2. It is password-based authentication, because not all networks have a PKI deployment or certificate authority or certificates to deploy to the clients on the network. The nice thing with PEAP-MSCHAPv2 is that you can have a single sign-on with user name and password, and this still enables both machine and user authentication to occur. And you can use the Windows logon credentials automatically. This is a default setting, so that when someone logs on, they automatically start using PEAP with the credentials that they've already entered during Winlogon.

Here's the properties pane of PEAP (slide 17). We have here, by default, the Fast Reconnect feature is disabled (Enable Fast reconnect box is not selected). And over here, we have Validate server certificate box, just like we had in regular EAP-TLS connection. And then we have down here, use Secured password (EAP-MSCHAP v2). This is where, if you hit the Configure button, you can change between machine-based certs, or user name and password.

And then you have here, Automatically use my Windows logon name and password (and domain if any). If there is any domain, it can also be used here, too. If this is selected, again, you'll save the users the step of actually having to even input credentials, using PEAP.

One more thing: Fast Reconnect, you can enable this. This is the idea that during phase 1 of authentication using PEAP, we create an encrypted channel. In phase 2, the auth method, TLS or MSCHAPv2 is used (in this case, it's MSCHAPv2). For reauth, though, the context is cached and so phase 2 isn't actually done during reauth, only the initial authentication, so this can make roaming easier. This can make reauthentications quicker.

I want to just talk about WEP here for a little bit (slide 18). Wired Equivalent Privacy keys have two different types of keys that are used. You have the pairwise key, which is the unicast key; and you have a group key, which is a multicast key. Session keys are derived on the client and on the remote authentication server. You can use any EAP method supporting dynamic key derivation when using WEP. And the RADIUS server transmits master session keys to the access point. Unicast keys are used to encrypt the EAP over LAN (EAPOL) key packet. This specific thing is encrypted.

Now, one point I want to emphasize. The RADIUS server transmits master session keys to the access point using the shared secret that's provided from the authentication server to the EAP, something you manually put on the EAP.

Because there are various weaknesses with WEP, such as tools on the Internet to break WEP keys and during 802.1x traffic using the clear, both for authentication and reauthentication, the Wi-Fi Alliance came up with a subset of IEEE 802.11i spec dealing with WPA or Wi-Fi Protected Access (slide 19).

With WPA, we use Temporal Key Integrity Protocol (TKIP) as a replacement for WEP. And with TKIP, we have a four-way handshake for key exchanges and we also do a periodic rekeying. Rekeying occurs by setting a timer on the AP for a certain period of time, and after that certain period of time goes, a re-key occurs. EAP changes are more secure with WPA because keys are never directly used. Only the derivatives of the keys are used with 1x, as opposed to in WEP.

Now, with the IEEE 802.11i specification, they have a revised key handshake, which will increase and enhance security for our networks, and it also has the idea of pre-authentication. Now what pre-authentication is, is once you connect to an access point with a specific SSID, say, SSID number 1, if you have other access points on the network with the same SSID, you can actually pre-authenticate with all of the other APs on the network. And what this does is it allows during a roaming scenario when you roam from one AP to the next, it allows roaming to be something that will happen a lot quicker because pre-auth has already occurred.

And lastly (slides 20-21), we just have some additional resources for deploying 802.1x. There are resources on our Microsoft.com Wi-Fi Web site that talk about 1x and our 1x authentication client, and other things about security and deploying wireless technology.

And that's going to be it for our WebCast today. What I'd like to do is transfer now and start our Q&A session for those of you that have questions.

Otto Cate: Great. Thank you very much. At this point, we'd like to hear from you, our listeners, about this topic and again, you can submit any comments or questions for Jeff today in the Q&A panel there, located towards the bottom of your screen. [This option is available only during the live Support WebCast presentation.] If you find that you need some more complex technical assistance today that might be outside of the scope of today's discussion, feel free to go to support.microsoft.com directly or contact our Product Support Services via phone to speak to a support professional.

If you'd like some more information on future Support WebCasts, or to review any of our sessions on demand, visit our main Support WebCast site there at support.microsoft.com/webcasts and for this particular session, you'll find the downloadable version these slides and on-demand streaming media there within 24 hours, and we also plan to have a full written transcript available for you within two to three weeks.

So with that, let's go ahead and answer some of these questions that were submitted during the slide presentation.

The first one is as follows: Cached credentials on a wireless connection, using PEAP, is an issue at our company. Will Microsoft be offering an option to enable or disable that option? Currently, my understanding is that the user credentials on an 802.1x connection are cached with no option not to cache.

Mihai Peicu: In our initial design, we considered this as an advantage for the user not to have to reenter the keys and we cache by default, the credentials of the user, the user name and password. And surely enough, if for some reason the credentials have changed (for example, the user changes the password), on the first failure, we re-prompt the user for the new credentials. However, as in your particular case, some customers don't like this option. We are looking now for the design of future releases or for your operating system, and how we can mitigate this issue. At this point, I cannot give you a definite answer. However, it is a problem that we are looking into. Thank you so much for that question.

Otto: Next question. Does EAP-TLS smart card authentication work with the DOD common access card?

Mihai: Thank you for the question. I'm afraid I'm not familiar with the DOD common access card. So I'm afraid I cannot give you the right answer, but if it's a standard smart card, it works. If there are any particular changes to that smart card that makes it non-standard, it may be a problem. I don't know the particular case of this DOD card. Thank you so much.

Otto: Next question. Certificates are great for machine authentication, but one-time passwords, for instance, RSA SecurID, are in many cases preferable for a user authentication. How would this be supported in Windows? I know that RSA is in the process of releasing Secure ID for Windows, but we're wondering if that also fits in with the 802.1x supplicant.

Mihai: Yes, we have a plug-in model for third-party EAP methods and SecurID is supposed to be able to plug into this model. So, I believe that, yes, SecurID is going to work with our implementation with 802.1x. I cannot give you a positive answer because we haven't really tested in our labs, but our plug-in model should enable it to work. Thank you for that question.

Otto: With PEAP-MSCHAPv2, how does one enable machine authentication, but not enable user-based authentication. Is that possible?

Mihai: Yes. This is possible. And it is possible through the 802.1x configuration page. There is a check box there that is checked by default, and this a check box that enables the machine authentication. If a customer wants to disable machine authentication, he just needs to uncheck that box and on this particular interface, the machine authentication is going to be disabled. That is not global — the check box that disables the machine authentication for all the interfaces that are present on that PC. So you may have machine authentication enabled on one interface and disabled on another interface. Thank you for that question.

Otto: Is there a method to enable 802.1x with PEAP to a computer that will be connected to a wired LAN via an automatic method? For instance, we'd like to be able to enable 802.1x with an installer or possibly VBScript (Visual Basic® Scripting Edition) without using the scripting.

Mihai: So in the resource kit, there is a tool that is called WZC tool that is publicly available and works on Windows XP Service Pack 1, and is able to set the wireless configuration settings and is able to enable or disable 802.1x on a particular interface. So besides the normal user interface, I see this as a possibility. Thank you for the question.

Otto: Can you clarify what Fast Reconnect does again?

Mihai: Yes, sure. Thank you for the question. It is similar to the previous one. Fast Reconnect. In order to understand Fast Reconnect, you probably need to think about the phases that PEAP authentication has. And in PEAP authentication, you have the first phase when you actually build the channel, the secure channel; and then on that secure channel, you run an inner authentication method and that in our case in Window's case, we have implemented inside PEAP-TLS or MSCHAPv2. So the first time the connection, in the first authentication that happens, these two phases are going to happen: the first is the PEAP phase when the channel is built, second is the inner authentication method that is performed.

Once the first authentication happens, if the Fast Reconnect feature is enabled both on the client and on the server, both the client and the server are going to cache the context resulting from the first authentication. And mainly, it is the TLS handle that is generated.

On subsequent re-authentications, in order to speed up the process, as far as the context is saved on both sides, only the first phase is going to happen, so that the exchange of handles, and that can verify actually, that the same entities that did a full authentication before are exchanging the messages, and then the reauthentication method is going to be skipped, so not performed. And because of this, the total time that the authentication process takes is a lot shorter. And the roaming, if the authentication itself happens on roaming, it works faster. And even if it's not a reauthentication, it's just on a roam, it just a session time-out. We are going to generate less traffic on the network, so the authentication is going to require less bandwidth from the network. So mainly, these are the advantages and this is the price that happens. Thank you for the question.

Otto: Is there an add-in to Windows 9x clients for 802.1x?

Mihai: Yes. We back-ported 802.1x to Windows NT® 4.0 and to Windows 9x. However, it is a limited release and I am not sure I know the exact details. I know that it's offered only on request to our enterprise partners. I can probably get back to you with more details. I don't know of all the details right now. Thank you.

Follow-up information: You can find specific information on http://www.microsoft.com/wifi/:

Otto: When using PEAP, can we use a RADIUS server, IAS, to authenticate against other DBs, other than Active Directory®?

Mihai: It depends on the backend RADIUS server that you are using. I am not sure what other companies' RADIUS servers are doing, so mainly in our presentation, we talked about Internet Authentication Service, which is a Microsoft product, and is the Microsoft implementation for RADIUS. So I cannot give you an answer for what other products are doing; however, the Internet Authentication Service is built with the idea that it is going to work with Active Directory.

If you want to know more about our implementation of the RADIUS server and our Internet Authentication Service, there was a WebCast in November last year (2003) specifically on this subject, so I believe that is probably the best place to listen and understand more about our implementation of the RADIUS server. Thank you for the question.

Otto: Why would I use 802.1x on my wired network if I have security through domain membership? Is it, perhaps, just another form of security? And is everything, in addition, everything that was talked about today, does everything have to actually go through RADIUS?

Mihai: There are cases when the physical security of the wired network is not enough, so there can be visitors, guests, that actually have physical access to the wired ports in the lobbies of offices, and the network does not really protected. People can connect and reach the network, I mean, the internal local area networks, the internal LANs. So what 802.1x offers for the wired network is a controlled access. At any point, the network administrator can know what machines are actually accessing the network, because of the machine authentication and what users actually are accessing the network because of user authentication. And if an unauthorized person tries to access the network with an unauthorized machine, then the port will actually be blocked, so even that attempt, that failed attempt, can be seen through the back-end server logs and the administrator can be alerted. Thank you for the question.

Otto: Okay. Next question. I believe that Wi-Fi can be used with PDAs, and we're wondering how they handle connections? Is it just like the PDA is docked when it's in a Wi-Fi zone?

Mihai: Yes, Wi-Fi can be used by PDAs. The same wireless interfaces work on PDAs, too. And the same standards, actually, are implemented on PDAs, too. So if we are talking about the Pocket PCs, Windows CE has an implementation of 802.1x protocol that works actually on 802.1x-enabled wireless networks. We just haven't mentioned it here, because we are focused on PCs not on PDAs, but we have the same Microsoft release of the 802.1x client for Windows CE. Thank you for the question.

Otto: Okay. And this may actually be a duplicate question, one that we had previously addressed, but I'll go ahead and throw it out, just in case. For computer authentication, we would prefer to not use certificates and instead use the machine account and password via MSCHAPv2 and we're wondering if that's possible, and if so, what security concerns would we have?

Mihai: Thank you for this interesting question. Yes, this is exactly right, so we use computer certificates only for TLS authentications, so for TLS machine authentications. For PEAP-MSCHAPv2, we actually use computer passwords and is exactly right, we use a user password. And that doesn't require public infrastructure, doesn't require a downloading of any kind of machine certificates to the particular PC. So, yes, this is right. Computer certificates are used only for the EAP-TLS. Thank you for that question.

Otto: With IAS, PEAP, and a Cisco 6500 switch, I'm seeing an event of "A malformed RADIUS message was received from the client" and then a packet that says, "User ABC was denied access." What might be the possible causes of this scenario?

Mihai: Thank you for the question. It's an interesting question, but I'm afraid we'd have to follow up on this because it is hard to give you an answer without actually seeing some logs or some sniffs off of the actual packet. And what is actually more important is what phase of your authentication this happens in. The message that you see on the server, with a malformed RADIUS packet, can be as well — I don't want to speculate and just saying it can be as well — a problem with a switch that is instructing that RADIUS packet and sending it to the back-end server. So we probably need to follow up offline on this question and get more details from you. Thank you so much.

Otto: In this case, since we would require details from the user, I'm thinking that this would probably be, perhaps, best handled via a support incident or something of that nature. Is there a specific area that we can contact PSS in this case?

Mihai: Yes, sure, yes, contact Networking for Windows. They can probably handle it or it can be escalated and then we look at it here.

Otto: Okay, great. Thank you. If you're using a group called Wireless in your IAS policy to allow specific users to access the wireless network, do you actually have to add the machines to the group in addition to adding the users that need access? And is that different if you're using EAP-TLS versus PEAP?

Jeff: Thank you very much for the question. The answer to that question is that you'll have to add the machines and the users. That's a simple answer for you. And is it different between using PEAP and EAP, I believe, is the question. It is not. Thank you very much.

Otto: Okay. During the presentation, there wasn't much regarding Windows 2000 support and/or configuration of wireless settings via the wireless Group Policy extensions. Can Windows 2000 be configured via the wireless Group Policy extensions?

Mihai: So there is a Group Policy implementation that is released only for Windows XP. The Windows 2000, it is a more limited release. It doesn't actually have also the integration with wireless configuration, and it doesn't have the Group Policy implementation. In order to do all that, you would need actually a lot more back-porting from Windows XP. So as you probably know, the Windows 2000 802.1x implementation was released after the release of Windows 2000, so it was released in a service pack. And as you probably know, the service pack additions are really limited. So, for now, Group Policy is not offered for Windows 2000, only the 802.1x protocol is all we have released for Windows 2000. Thank you for the question.

Otto: Okay. And just a clarification question, here: It is my understanding that PEAP-MSCHAPv2 does not use certificates. Is that correct?

Jeff: You are correct, in that PEAP, using MSCHAPv2 does not use certificates. EAP-TLS uses certificates, however.

Mihai: I would like to clarify a little bit more. The may be confusion here and that is part of the PEAP nature of authentication, so MSCHAPv2 doesn't use certificates. However, if you want to do mutual authentication, you still need to have the certificate that comes from the server verified, yes? And because of that, you need to have in your root certificate store on the client, a certificate from the entity that released the server certificate store. That can be a public entity, so I'll just give an example.

It can be any company that puts certificates out, like VeriSign or any company. So, you probably know that when the operating system is installed, it actually installs in the trusted root certificate store with a number of certificates that are public certificates released by different companies. And exactly like it happens, for example, with SSL when you connect to a secure site over a Web interface, exactly the same way for PEAP you can have this secure channel built based on these trusted root certificates. So this probably clarifies your question. Thank you for the question. It's a very interesting question.

Jeff: Yes.

Mihai: I believe that the question is about actually, the first time when the machine is installed, and you need to bootstrap the process and join the domain. So this would probably, so the fact that it is .11a or .11b or any kind of card would not make a difference. However, if the wireless network is 802.1x-enabled and the machine is not joined to the domain and it doesn't have certificates downloaded, then you would not be able to actually access the network.

So then how can this be done? There are several ways that this can be done. One is, the first time around, you just connect it through a wired interface, download certificates, and then, based on that authenticate, get access to the network, and join the domain. Another way would be to have a certificate on a smart card and just first time around, you use that and join the domain, and then be able to download certificates. Yes, this is about it. So, there needs to be a way to bootstrap the first time.

Jeff: But you can also use PEAP-MSCHAPv2. That's not one of the options that the person asking the question has offered though. But a user can configure PEAP with MSCHAPV2 and provide credentials that way.

Mihai: Yes.

Jeff: You could.

Mihai: Yes, for that case. Yes, thank you for the question.

Otto: Are they any authentication issues when transmitting data and changing service access points during the transfer with the device? For instance, if we're moving about while transmitting data and the nearest server access point happens to be changing?

Mihai: I believe that the question is regarding the timing of a roam. So unless there is a really time-critical application, like video streaming, there are no problems at all on roaming from one access point to the other. The authentication process is fast enough that any normal application with the exception that I mentioned of video streaming, may have a hiccup, yes? But otherwise, any application would just keep up and the user wouldn't notice any interruption in connectivity. Thank you for the question.

Otto: If I'm using EAP-TLS, is it safe to say that any information passing from the computer to the server is encrypted, once I'm authenticated through my RADIUS server?

Mihai: Yes. There is no real specification here if it's a wireless network or a wired network. I believe that the question is about the wireless network. So once the client gets authenticated for a wireless network, yes, the connection is encrypted at layer 2. So that means that it's going to be a Web encryption between the client and the access point. However, if the question is about what happens before the authentication, so during the 802.1x traffic, then there is no layer 2 encryption, so there is no encryption between the client and the access point for 802.1x traffic. I believe this is the answer and, just to add a small note, this is an enhancement that Wi-Fi protected access brings for the reauthentication process that the traffic actually gets encrypted.

So, now, about wired networks, there is no layered encryption for wired networks, so everything is passed between the client and the switch in here at layer 2. Thank you so much for that question.

Otto: Okay, great, thank you. Well, with that, it appears that we have answered all the questions that were submitted to the queue today, so I'm going to go ahead and wrap up our session, here. I certainly wanted to thank Jeff for coming out and giving us a great presentation. And I also wanted to thank Mihai for coming out and helping us during the Q&A here and of course, as always, we'd like to thank you, our listeners, for attending today's session. We'd certainly welcome any feedback on the sessions that we produce and the topics that you'd like to see covered in the future. You can visit the "Contact Us" page there at support.microsoft.com/servicedesk/webcasts/feedback.asp and select the link below WebCast Comments/Suggestions/Feedback.

We certainly hope that this information has been helpful to you and your business. We certainly look forward to your participation in upcoming WebCasts. And again, as a reminder, we'll have a downloadable version of the slides and an on-demand streaming audio archive available within 24 hours; and that'll be available there on support.microsoft.com/webcasts. Thanks, everyone. And have a great day.