| Summary: | NM connects to WPA2 Enterprise using PEAP-GTC with wrong password | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Jiri Koten <jkoten> | ||||||||
| Component: | NetworkManager | Assignee: | Dan Williams <dcbw> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | ||||||||
| Severity: | high | Docs Contact: | |||||||||
| Priority: | urgent | ||||||||||
| Version: | 6.2 | CC: | danw, jklimes, tpelka, vbenes | ||||||||
| Target Milestone: | rc | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: |
No documentation needed.
|
Story Points: | --- | ||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2012-06-20 13:42:29 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Attachments: |
|
||||||||||
|
Description
Jiri Koten
2011-11-24 13:09:20 UTC
If this is the issue I'm thinking about we fixed it previously NM 0.9 in these commits: 6187b85052644f212d12ba6f76c60c4c14f70f79 a27cd8e5d95e4f5a1c54d6dc2515feb2bb861444 backports attached. Created attachment 547524 [details]
Backport of a27cd8e5d95e4f5a1c54d6dc2515feb2bb861444
Created attachment 547525 [details]
Backport of 6187b85052644f212d12ba6f76c60c4c14f70f79
These patches will immediately ask for a new token code if the EAP exchange fails. What might be happening is that the token is slightly out of sync and the initial access attempt fails because of that. NM will keep trying the token code a few times before giving up, which is pointless, because it already failed :) These patches should address that issue. This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release. Used the patches from comment #8 and comment #9. The first one needed a change, because supplicant states were consolidated in later NM versions (> 0.8.1). However, testing shows this two patches did *not* fix the issue. I'm still able to re-connect with the wrong password. I suspected "proactive_key_caching" that might be the reason, but deactivating it didn't help either. So, deeper inspection is needed. The reconnection to the same AP succeeded (after an initial connection had been established) because of PMKSA caching. This is the feature in 802.11 that is used for more easy roaming and for enhancing performance for delay-sensitive applications during re-associations. STA sends PMKID, with is an identifier of a security association. AP founds it has the same association and allows to skip authentication and proceed to 4-way handshake. References: * section 8.4.1.2.1 of the IEEE 802.11-2007 standard http://standards.ieee.org/about/get/802/802.11.html * csrc.nist.gov/publications/nistpubs/800-97/SP800-97.pdf section 5.4.4 Pre-Authentication and PMKSA Caching (In reply to comment #20) > The reconnection to the same AP succeeded (after an initial connection had been > established) because of PMKSA caching. This is the feature in 802.11 that is > used for more easy roaming and for enhancing performance for delay-sensitive > applications during re-associations. > > STA sends PMKID, with is an identifier of a security association. AP founds it > has the same association and allows to skip authentication and proceed to 4-way > handshake. > > References: > * section 8.4.1.2.1 of the IEEE 802.11-2007 standard > http://standards.ieee.org/about/get/802/802.11.html > * csrc.nist.gov/publications/nistpubs/800-97/SP800-97.pdf > section 5.4.4 Pre-Authentication and PMKSA Caching Yeah, this is pretty much expected and this is the only way roaming with GTC can actually work; otherwise youd always have to re-enter your PIN code every time you walked got in range of a new AP. If you've proved your identity once then as long as you follow the protocol you're allowed for a certain period of time. I think we just expect this behavior, and since it's the result of manual action (reconnecting explicitly) I think we can ignore it. If, however, the connection drops for a period of time (say, 5 minutes?) and then you come back to your machine and enter the *wrong* PIN code to reconnect, then I guess I'd expect things to fail. If they don't, then we probably have a bug in the supplicant that the PMKSA cache isn't cleared at the right times. I do recall some fixes to PMKSA in the supplicant over the last year or two, so perhaps we should verify this by connecting, then sending the supplicant a disconnect request with dbus-send, and then waiting for NM to reconnect and ask for secrets, then waiting say 5 minutes and then entering the wrong PIN.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
No documentation needed.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0832.html |