Re: dot1x specification EAPOL-Logoff clarification
Hi 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 ?! The problem is not within the standard, but how to build a system out of several ones. From the standard point of view, I still think that not confirming EAPOL-Logoff is a valuable design choice. As opposed to not have signed it :-) I guess there is no standard which could reign over the application of other standards. These things are usually called "best practices". But I doubt there is one for multi-tier network access authentication with per-minute accounting :-) 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. Given the ease of this DDoS attack, I usually propose to ignore any EAP-Logoff altogether within the Authenticator PAE - if possible. As I said, this decision is up to the AuthServer. If the Session-Timeout is very short in respect to your Accounting intervals necessary for billing, I think you do not need to rely on it. artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: dot1x specification EAPOL-Logoff clarification
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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: dot1x specification EAPOL-Logoff clarification
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. 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. 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. 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
Re: dot1x specification EAPOL-Logoff clarification
Hi On 30 Apr 2008, at 14:08, Alan DeKok wrote: 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*. ;-) Yes, right. Freeradius is very cool :-) 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. 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. and typically are in different (logical) subnetworks (VLANs, etc.) Imo, no standard protocol exists designed to do such things. There is interest. Of course there is :-) But no protocol. artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: dot1x specification EAPOL-Logoff clarification
Hi Alan On 30 Apr 2008, at 13:50, Alan DeKok wrote: 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. 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 and typically are in different (logical) subnetworks (VLANs, etc.) Imo, no standard protocol exists designed to do such things. Obviously, it is possible but a bit cumbersome in practice. One might ask oneself if it makes sense. 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... :-) 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. artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: dot1x specification EAPOL-Logoff clarification
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. 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. 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. 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... 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 :-) Thanks for your input Artur. Discussing standars is fun :-) Thanks artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: dot1x specification EAPOL-Logoff clarification
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. 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. 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. 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 ([EMAIL PROTECTED]) 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
Re: TTLS authentication slow
Hello Allan On 14 Nov 2007, at 00:15, Allan Riordan Boll wrote: >> Maybe I missed it, but what client do you use? Windows does not yet >> support TTLS natively. yes sorry, i forgot to say. I am already using SecureW2 of course. And it does work, it's just very slow at authenticating... Also, I'm using FreeRADIUS 1.1.7. ok, that's what I thought, but there are people outthere actually using other stuff (wire1X, xsupplicant, etc). from the experience, SecureW2 TTLS works just fine with freeradius. but just for the sake of an experiment, maybe you could also test PEAP. that should not change anything from the freeradius user DB perspective. Well, the default config had the same problem. That's why I tried writing one from scratch, to make sure there wasn't some obscure module making the server hang. Is this an unusual approach to write a config from scratch, or is it a good idea? Would love to hear what's normal. the default config should work just fine. what I would do in your position is simplify stuff. I did not look at your config, but: - try PEAP with the built in windows EAP peer and then TTLS with the SecureW2, see if something changes; - in the standard config, both should work as soon as you add a user with a User-Password to your users file. in the beginning and for testing, don't use databases, maybe your server has difficulties connecting to it, or something. - if the server replies correctly with -X, then this is probably a user right issue. - to me it looks like some issue with the server certificate validity (mutual authentication). how did you configure SecureW2? does it verify the server certificate? does it ask the user if the certificate is unnknown? the best would be to add the signing CA to your trusted roots at the windows pc *before* any authentication tries. you should verify that the server certificate is correctly verified by the windows pc (simply download the server certficate in .der format and open it in the explorer. it should not say "untrusted"). it would be *very* surprising if the communication were still as you described it. what authenticator do you use? artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: TTLS authentication slow
Allan, Maybe I missed it, but what client do you use? Windows does not yet support TTLS natively. Artur On 13 Nov 2007, at 16:23, Alan DeKok wrote: Allan Riordan Boll wrote: The problem is that authenticating takes around 20 seconds. While running the server in a terminal with the -X flag, I see that my Windows XP client first makes one TLS request, then waits ~20 seconds, then makes two more TLS requests and four TTLS requests all together taking less than one second. After these last six requests the client is immediately online. It sounds like a weird Windows issue... Can anyone hint me on why the client waits for so long before doing the requests it needs? Is my Freeradius server erroneously defaulting the client to use TLS instead of TTLS, and confusing the client? No. Many people are running FreeRADIUS with Windows clients (XP SP1, SP2, Vista), and most authentications happen very quickly. I'm not sure why the Windows machines would take so long. Maybe try it with a different access point. I've written a radiusd.conf from scratch, so that the server only runs the modules I actually use, hoping this is safer and easier to administrate. Please feedback if anyone have any comments on this approach. If it works... If it doesn't work, go back to the default config. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/ users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: in vs. out
David Just one word on it: you are citing a RADIUS specific RFC. Thus, Acct- Input-Octets is the value perceived by RADIUS instances. RADIUS RFCs cannot possibly specify how terminals, wireless cards, GSM phones etc. should or should not count packets, traffic, connections, etc. It can and it does specify how NAS (radius-client) should communicate with the AS (radius-server). Thus, the situation here is from the NAS point of view(*) and the INPUT means INPUT to the NAS from the service port, i.e. e.g. from the user as Alan explained. Any other interpretation would be imho very strange, no? Artur PS or from server's point of view if you prefer. Since RADIUS is a distributed AAA system, it's whole sense us to establish the same view after a while through protocol exchanges. (ah) On 4 Oct 2007, at 09:17, Alan DeKok wrote: [EMAIL PROTECTED] wrote: It is curious, then, why the RFC isn't as definitive in the definition... I suppose it is intentionally left open for vendor interpretation. No. The RFC *is* definitive. It just may not be overly clear, 10 years after the original text was written. It is NOT left open for vendor interpretation. If it was, then Acct-Input-Octets would be *useless*, as you could never tell what it meant. As such, portmaster being more specific as it relates to their products isn't surprising. But, is that the 'standard', a 'best practice', or just one vendor's (albeit, a very in-the-know vendor's) implementation? I do agree with the point of view (of the port), in theory. However, in practice, I guess the best answer is that it is vendor specific.. hmm. No. The standard is the RFC. The portmaster text is just additional text from the people building RADIUS systems. It is NOT vendor specific. Do NOT say it is vendor specific. Follow the standards. Do not follow broken vendors. It actually isn't just that one vendor... in fact, if not mistaken, much of the commercial wlan gear I've worked with used the above meaning. It would be curious to see a list of vendors and how they implemented their accounting... if we all checked the manuals of the devices we use, we could all help build that list in the freeradius wiki! Feel free to start this effort. There are many other vendor products that are very broken with respect to RADIUS. Do NOT follow any individual vendor, or even groups of vendors. Follow the standards. If the standards aren't clear, ask on the IETF RADEXT mailing list. The people there should be able to give conclusive answers. Also see my 2 documents in that working group. They clarify many issues and problems with the previous RADIUS RFC's. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/ users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP fragment size clarification needed
Hello On 24 Sep 2007, at 09:58, Alan DeKok wrote: Stefan Winter wrote: I wonder what the sentence about MAX packet size on APs is about. Is it their maximum allowed length of a RADIUS packet? Frankly, that would be quite stupid because packets can legitimately be much larger than that. (-> RADIUS implementation problem on AP) The problem is that neither EAP per se nor EAPOL support fragmentation/reassembly, only certain EAP methods do. These however, by design, are not implemented on the NAS (i.e. AP). So you get a problem on the link when exceeding link MTU. So if the above holds true, I would much rather set fragment size to 1500, and fix any upcoming impl problems that have nothing to do with EAP frag size, rather than yield with my frag size. That's why it's configurable. Others have reported issues with fragment sizes larger than 1024. Some even need it to be less. Alan DeKok. Set it to 1500 and try it out. If it works with your APs, fine. The RFC 3748 and the RFC 4017 only dictate Minumum MTU: From RFC3748 (interesting reading, explains the situation) [4] Minimum MTU. EAP is capable of functioning on lower layers that provide an EAP MTU size of 1020 octets or greater. EAP does not support path MTU discovery, and fragmentation and reassembly is not supported by EAP, nor by the methods defined in this specification: Identity (1), Notification (2), Nak Response (3), MD5-Challenge (4), One Time Password (5), Generic Token Card (6), and expanded Nak Response (254) Types. Typically, the EAP peer obtains information on the EAP MTU from the lower layers and sets the EAP frame size to an appropriate value. Where the authenticator operates in pass-through mode, the authentication server does not have a direct way of determining the EAP MTU, and therefore relies on the authenticator to provide it with this information, such as via the Framed-MTU attribute, as described in [RFC 3579], Section 2.4. While methods such as EAP-TLS [RFC 2716] support fragmentation and reassembly, EAP methods originally designed for use within PPP where a 1500 octet MTU is guaranteed for control frames (see [RFC 1661], Section 6.1) may lack fragmentation and reassembly features. EAP methods can assume a minimum EAP MTU of 1020 octets in the absence of other information. EAP methods SHOULD include support for fragmentation and reassembly if their payloads can be larger than this minimum EAP MTU. However, I read once somewhere (cant' recall where) that in practice, it is *not* recommended to exceed approx. 1200 bytes MTU. Artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: RFC 3579 and Access-Accepts
Stefan, the message included seems to me an EAP Success message (Code 0x03) and in no way an EAP Message/EAP Request/Notification (would be 0x01yy02). I do not see the problem at a first glance - am I mistaken? Artur On 19 Sep 2007, at 13:11, Stefan Winter wrote: Hello, it seems that FreeRADIUS is sending an EAP-Message fragment along with its Access-Accepts, as in: Packet-Type = Access-Accept Wed Sep 19 11:59:25 2007 MS-MPPE-Recv-Key = stuff MS-MPPE-Send-Key = morestuff EAP-Message = 0x03070004 Message-Authenticator = 0x593773a711f50bd8b4ce98434a7e1590 User-Name = "[EMAIL PROTECTED]" Proxy-State = 0x323039 Whereas RFC 3579 , chapter 2.6.5 says: "An EAP-Message/EAP-Request/Notification SHOULD NOT be included within an Access-Accept or Access-Reject packet." This is now the second RADIUS implementation I see that behaves like that - is there a reason for the EAP-Message and something wrong with 3579, or is that SHOULD NOT just ignored by most? Greetings, Stefan Winter -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: [EMAIL PROTECTED] Tel.: +352 424409-1 http://www.restena.luFax: +352 422473 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/ users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Authorization in RADIUS, Authorization in freeradius
Hi George I guess it is more a question of definition of the scope of the authorization and authentication than of the actual mechanisms. I would invite you to read the RADIUS RFCs since your conclusions sound a little bit hasty. In RADIUS and in freeradius in particular the authentication is part of the authorization. This might sound somewhat strange, but is actually a sound and more general alternative from the AAA perspective, i.e. from an authenitcation service point of view. It goes like that: identification vector -> authorization -> authentication -> everything else. You could reflect upon it in terms of phases, although strictly speaking the whole treatment is applied on a per packet basis. It is of course true that one can do a lot of things with RADIUS (and especially with freeradius), that might not directly correspond to the initial goals, but I do believe that logically and generally one could speak about these phases. Thus, a user (or machine, or address or user logging in from certain mac address or whatever else is used as identity) can be allowed or not to use certain authentication schemes. Once a method is chosen, the claimed identity (or another one, unfortunately) can be verified during the authentication. If this verification of the identity (=authentication) is successful, certain parameters are transmitted to the NAS in the Access-Accept packet. These are to be applied to the service to be delivered. It could be duration, QoS parameters, service types, etc. - that is utterly dependent on the service and on the NAS and often employs a bunch of VSAs. So for me most definitely things such as Session-Timeout, the Tunnel attributes, and the most VSAs are authorizations, because these are properties to be applied to the already accepted service delivery for an authenticated identity. Now, there are other attributes (almost all of them, to cite Alan) that are actually authorizations. E.g. the same verified identity can be granted service access in certain conditions and not in the others. These conditions can be time, location, accounting (e.g. previous resource usage), roaming etc. related. E.g. you could allow only any member of a group A access to certain WiFi Access Points during certain time periods if and only if this particular member did not use up its resource limit. At the same time a group B could access all the other Access Points, etc. If that is not authorization for you, please explain your definition, since it would interest me personally. I do confess however that this particular scenario mixes up RADIUS and freeradius capabilities, but that seems normal since IETF protocols rarely specify behaviour. That leads to your question on policies. Policies also need a definition: what is a policy for you? In the broad common sense of the word, policies are not part of the RADIUS protocol. However you can quite easily implement policies in freeradius e.g. by grouping and actual resource usage (see example above - "during the course hours students are not allowed to login WiFi from the cafeteria", is that not a policy for you?). Depending on NAS capabilities and service to be provided, you can do more complex things... Is that helpful? artur On 2 Sep 2007, at 17:52, George Beitis wrote: Hey Alan, thank you for your reply. I am writing up a part of my dissertation and I 'm referring to freeradius and the RADIUS protocol trying to explain how it works. From my research most people who use RADIUS for authentication purposes. Noone gives a clear image of whether or not they use it for authorization once they established authentication, so in other words authentication and authorization become one the same. Do you know of any products that can be used with freeradius to provide such authorization facilities? Using perhaps policies? regards George Alan DeKok wrote: George Beitis wrote: I have a general question regarding Authorization in the RADIUS protocol and how it is implemented in freeradius. What does the RADIUS protocol refer to when it talks about Authorization, does it actually refer to users being probably authorized after being authenticated, using the protocol? I guess. It's not really clear. i.e. No one knows... Are there RADIUS specific attributes that are for authorization? (not authentication). Most of them? The authentication attributes are User-Password, CHAP-Password, EAP-Message... and not much else. Most everything else are authorization related. There are ways of implementing authorization into freeradius, but do those simply overwrite the authentication decision? I have no idea what you mean by that. DIAMETER provides such authorization messeges from my understanding but the RADIUS protocol does not talk about any, is this correct? Diameter is useless. It's a wonderful theoretical desi
Re: pre1 dies on startup: generate_sql_clients() returned error
Regarding the subject, it's still much better than the following headline: "A startup dies on pre1" :-))) Sorry, couldn't help thinking of it when reading the mail. Anyway, a hale to the project that has already helped so many new companies to construct their businnesses... On 28 Aug 2007, at 10:29, Alan DeKok wrote: Arran Cudbard-Bell wrote: I know you like to kill the server off if theres any kind of configuration parsing error; but possibly duplicate/invalid clients is one of the exceptions where it might be better to complain bitterly... This goes for invalid clients, invalid home servers, databases that are down, etc. The list is nearly endless. It's difficult to write all of the code to catch all of those error cases. And what does your policy do when it says "proxy to FOO", and FOO doesn't exist? Does your local configuration handle that correctly, or does something else go wrong? It's easier to force people to have working configurations. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/ users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: The "right" way to limit a user to one EAP Type
Replying to myself - here comes a possible resolution for this 'EAP- Type restriction per user/group' thread: A possible solution is to restrict EAP-Type but by using a different operator (man 5 users): "EAP-Type += " where method is one of (instead of ":=" for tunneled methods ; for non tunneled methods I think both should be fine). I tested it: with a MySQL backend, a user configured as EAP-Type += PEAP could use PEAP-MSChapv2 but not TTLS-PAP, while a user configured EAP-Type += EAP-TTLS could use TTLS-PAP but not PEAP. rlm/ eap - freeradius correctly reported "client wants to ttls, while we require peap, rejecting the user" (or vice versa). Not sure it is the intended way, so I hope the behaviour won't change in the next release. But it works. Greetings and thanks artur On 23 Jul 2007, at 13:14, Artur Hecker wrote: > Hi > > > On 23 Jul 2007, at 11:21, Phil Mayers wrote: > >> On Mon, 2007-07-23 at 10:20 +0200, Artur Hecker wrote: >>> Hello >>> >>> >>> In the default configuration, if a User-Password is defined for a >>> user, the user can be authenticated by all applicable authentication >>> types. That is the sense and the beauty of the default >>> configuration :-) >>> >>> However, in a practical deployment, a serious security policy is >>> likely to state the contrary: every user (or usergroup) should be >>> authenticated by exactly one authentication method. >> >> Why? >> >> Surely a method is either secure (in which case you'd let people >> use it) >> or insecure (in which case you'd let no-one use it)? >> >> I would consider our deployment "practical" (>20k users, almost 400 >> APs) >> and we don't care what method they use, as long as it's secure and >> generates keys. > > As I said, it is the matter of security policy, I cannot discuss it, > for it is not an opinion :-) > > What you say does make sense to me, but on the other hand I still do > not see why it should be possible to authenticate a user by more than > one method. From what you are saying, one would conclude that only > one method should be used for all users. But very often it depends on > the security level of the user group and the trust you have in user > capabilities (-> security policy...) > > I can give you real-world examples, which will certainly lead to > further discussions. > > Case 1: To accelerate deployment, company A considers that PEAP- > MSCHAPv2 should be used by all users not having a certificate. It had > the advantage to work immediately (say against internal AD with NTLM > or SQL, etc). However, user certificates are being issued over the > time period - for the same user identity. The point thus is to > prevent users who have obtained the certificates from keeping on > using old style password auth. > > Case 2: some "important users" still use TTLS-PAP but everybody > should use PEAP-MSCHAP-v2. You cannot deactivate TTLS-PAP even if you > consider it not good enough. You don't want others to use it though. > > Case 3: different backends are available, each storing a part of > users with password in clear and in hash forms. Needless to say, some > users are stored in both... Wireless admins have no power on these. > Thus, TTLS-PAP and PEAP-MSCHAPv2 are used interchangeably, in some > times by the same user, even if you feel like TTLS-PAP is less secure. > > And it goes on and on, even with EAP-MD5 in wired... Just don't take > the examples literally. What I am saying is that, very often, such > situations are linked to internal company processes, to compatibility > concerns, etc., sometimes you cannot deactivate an authentication > method for administrative reasons but you would like to restrain its > use as far as possible, etc. > > >>> What is the "right" (recommended) way to do it? Could not find >>> anything on that in Wiki. (Would be glad to add it, when finished). >> >> Do you want to restrict everyone to a single EAP type, or different >> people/groups to different EAP types? > > an EAP type per group and/or user. > > >>> Background: I used to restrict users by explicitly setting for them >>> (their group) EAP-Type := something, according to the user profile. >>> However, as of 1.1.6, my wireless PEAP(-MSCHAPv2) user >>> authentication >>> does not work anymore as before: the inner PEAP authentication fails >>> with "cannot tunnel TLS in TLS", most probably since the authorize >>> module (sql) sets EAP-Type := PEAP. It *may* be just me though
Re: The "right" way to limit a user to one EAP Type
Hi
On 23 Jul 2007, at 11:21, Phil Mayers wrote:
> On Mon, 2007-07-23 at 10:20 +0200, Artur Hecker wrote:
>> Hello
>>
>>
>> In the default configuration, if a User-Password is defined for a
>> user, the user can be authenticated by all applicable authentication
>> types. That is the sense and the beauty of the default
>> configuration :-)
>>
>> However, in a practical deployment, a serious security policy is
>> likely to state the contrary: every user (or usergroup) should be
>> authenticated by exactly one authentication method.
>
> Why?
>
> Surely a method is either secure (in which case you'd let people
> use it)
> or insecure (in which case you'd let no-one use it)?
>
> I would consider our deployment "practical" (>20k users, almost 400
> APs)
> and we don't care what method they use, as long as it's secure and
> generates keys.
As I said, it is the matter of security policy, I cannot discuss it,
for it is not an opinion :-)
What you say does make sense to me, but on the other hand I still do
not see why it should be possible to authenticate a user by more than
one method. From what you are saying, one would conclude that only
one method should be used for all users. But very often it depends on
the security level of the user group and the trust you have in user
capabilities (-> security policy...)
I can give you real-world examples, which will certainly lead to
further discussions.
Case 1: To accelerate deployment, company A considers that PEAP-
MSCHAPv2 should be used by all users not having a certificate. It had
the advantage to work immediately (say against internal AD with NTLM
or SQL, etc). However, user certificates are being issued over the
time period - for the same user identity. The point thus is to
prevent users who have obtained the certificates from keeping on
using old style password auth.
Case 2: some "important users" still use TTLS-PAP but everybody
should use PEAP-MSCHAP-v2. You cannot deactivate TTLS-PAP even if you
consider it not good enough. You don't want others to use it though.
Case 3: different backends are available, each storing a part of
users with password in clear and in hash forms. Needless to say, some
users are stored in both... Wireless admins have no power on these.
Thus, TTLS-PAP and PEAP-MSCHAPv2 are used interchangeably, in some
times by the same user, even if you feel like TTLS-PAP is less secure.
And it goes on and on, even with EAP-MD5 in wired... Just don't take
the examples literally. What I am saying is that, very often, such
situations are linked to internal company processes, to compatibility
concerns, etc., sometimes you cannot deactivate an authentication
method for administrative reasons but you would like to restrain its
use as far as possible, etc.
>> What is the "right" (recommended) way to do it? Could not find
>> anything on that in Wiki. (Would be glad to add it, when finished).
>
> Do you want to restrict everyone to a single EAP type, or different
> people/groups to different EAP types?
an EAP type per group and/or user.
>> Background: I used to restrict users by explicitly setting for them
>> (their group) EAP-Type := something, according to the user profile.
>> However, as of 1.1.6, my wireless PEAP(-MSCHAPv2) user authentication
>> does not work anymore as before: the inner PEAP authentication fails
>> with "cannot tunnel TLS in TLS", most probably since the authorize
>> module (sql) sets EAP-Type := PEAP. It *may* be just me though.
>
> Yeah, don't do that. Have something like:
>
> authorize {
> preprocess
> eap
> files
> }
>
> in "users":
>
> # group "foo" must use PEAP
> DEFAULT My-Group == "foo", EAP-Type != PEAP, Auth-Type := Reject
>
> # group "bar" must use TTLS
> DEFAULT My-Group == "bar", EAP-Type != TTLS, Auth-Type := Reject
That's my problem - I think this cannot work with tunneled methods.
I think that with this config the user will be rejected whenever the
inner method has to check the password (the type is not PEAP -> Reject).
I'm not sure since this explicit reject does not work with an SQL
backend. But I already tried the inverse logics "EAP-Type == PEAP"
instead. SQL starts by saying "no matching entry in the database
[...]", I guess since it does not find EAP-Type set to PEAP in the
first request. In the given situation (PEAP by default), that's fine
for the tunnel to start. It even finds the matching rows during the
requests in between. But, as I said, it fails when it comes to the
inner MSCHAPv2 check of the received response: it repeats "no
matc
The "right" way to limit a user to one EAP Type
Hello In the default configuration, if a User-Password is defined for a user, the user can be authenticated by all applicable authentication types. That is the sense and the beauty of the default configuration :-) However, in a practical deployment, a serious security policy is likely to state the contrary: every user (or usergroup) should be authenticated by exactly one authentication method. What is the "right" (recommended) way to do it? Could not find anything on that in Wiki. (Would be glad to add it, when finished). Background: I used to restrict users by explicitly setting for them (their group) EAP-Type := something, according to the user profile. However, as of 1.1.6, my wireless PEAP(-MSCHAPv2) user authentication does not work anymore as before: the inner PEAP authentication fails with "cannot tunnel TLS in TLS", most probably since the authorize module (sql) sets EAP-Type := PEAP. It *may* be just me though. thanks artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Roaming with WPA-Enterprise/Radius
hmmm, seriously though: - does anyone know of any APs on the market which support 802.11f? - has anyone ever seen a reasonable non-proprietary definition of the container content for the context transfer? - has anyone ever thought of implementing the support for 802.11f into freeradius? (i know alan hates its double-nested attributes :-) ) - what about the preauthentication definitions in 802.11i? ciao artur On 4 Jan 2006, at 14:07, Zoltan Ori wrote: On Wednesday 04 January 2006 07:07, DI PAOLA ., VIERI wrote: Is there a way of "caching" or "pre-authenticating" or "propagating authentication between APs"? Has anyone found a solution to this roaming problem in case one uses WPA-Enterprise/Radius? IAPP - IEEE 802.11F Zoltan Ori - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/ users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: help with EAP MD5 wired authentication
hi
the following line seems to be principally correct (don't use
explicit Auth-Type):
a User-Password == "a"
the eap module fails in authentication because it can't find the User-
Password for the user. Make sure that the "files" module is used in
authorize i.e. that the users file is actually used.
the modules pap and mschap are of no interest whatsoever. also, i
don't understand the DEFAULT accept policy - imho it's nonsense.
hope this helps
artur
1. modules section
...
pap {
encryption_scheme = crypt
}
# CHAP module
#
# To authenticate requests containing a CHAP-Password
attribute.
#
chap {
authtype = CHAP
}
...
$INCLUDE ${confdir}/eap.conf
mschap {
...
}
files {
...
}
...
The console output of radiusd -X -s is
Ready to process requests.
rad_recv: Access-Request packet from host 10.11.12.107:1024, id=76,
length=214
Framed-MTU = 1480
NAS-IP-Address = 10.11.12.107
NAS-Identifier = "HP ProCurve Switch 2824"
User-Name = "test"
Service-Type = Framed-User
Framed-Protocol = PPP
NAS-Port = 24
NAS-Port-Type = Ethernet
NAS-Port-Id = "24"
Called-Station-Id = "00-0f-20-8d-04-c8"
Calling-Station-Id = "00-c0-9f-0d-4a-1f"
Connect-Info = "CONNECT Ethernet 100Mbps Full duplex"
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = "1010"
EAP-Message = 0x020200090174657374
Message-Authenticator = 0xb12214c2d6fb14f33c7cc758ccfb54b7
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 0
modcall[authorize]: module "preprocess" returns ok for request 0
modcall[authorize]: module "chap" returns noop for request 0
modcall[authorize]: module "mschap" returns noop for request 0
rlm_eap: EAP packet type response id 2 length 9
rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
modcall[authorize]: module "eap" returns updated for request 0
users: Matched entry DEFAULT at line 152
users: Matched entry DEFAULT at line 171
users: Matched entry DEFAULT at line 183
modcall[authorize]: module "files" returns ok for request 0
modcall: group authorize returns updated for request 0
rad_check_password: Found Auth-Type EAP
auth: type "EAP"
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 0
rlm_eap: EAP Identity
rlm_eap: processing type md5
rlm_eap_md5: Issuing Challenge
modcall[authenticate]: module "eap" returns handled for request 0
modcall: group authenticate returns handled for request 0
Sending Access-Challenge of id 76 to 10.11.12.107:1024
Framed-IP-Address = 255.255.255.254
Framed-MTU = 576
Service-Type = Framed-User
Framed-Protocol = PPP
Framed-Compression = Van-Jacobson-TCP-IP
EAP-Message = 0x0103001604100118f4899111b27fc08900284095e5e2
Message-Authenticator = 0x
State = 0x33fe6026586af730cd367983bb9ea8b6
Finished request 0
Going to the next request
--- Walking the entire request list ---
Waking up in 6 seconds...
rad_recv: Access-Request packet from host 10.11.12.107:1024, id=77,
length=249
Framed-MTU = 1480
NAS-IP-Address = 10.11.12.107
NAS-Identifier = "HP ProCurve Switch 2824"
User-Name = "test"
Service-Type = Framed-User
Framed-Protocol = PPP
NAS-Port = 24
NAS-Port-Type = Ethernet
NAS-Port-Id = "24"
Called-Station-Id = "00-0f-20-8d-04-c8"
Calling-Station-Id = "00-c0-9f-0d-4a-1f"
Connect-Info = "CONNECT Ethernet 100Mbps Full duplex"
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = "1010"
State = 0x33fe6026586af730cd367983bb9ea8b6
EAP-Message =
0x0203001a04101c913399463bebf9f6dc2d0af18f0c7974657374
Message-Authenticator = 0x2592cd875d1068f5b16fe7999f451769
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 1
modcall[authorize]: module "preprocess" returns ok for request 1
modcall[authorize]: module "chap" returns noop for request 1
modcall[authorize]: module "mschap" returns noop for request 1
rlm_eap: EAP packet type response id 3 length 26
rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
modcall[authorize]: module "eap" returns updated for request 1
users: Matched entry DEFAULT at line 152
users: Matched entry DEFAULT at line 171
users: Matched entry DEFAULT at line 183
modcall[authorize]: module "files" returns ok for request 1
modcall: group authorize returns updated for request 1
rad_check_password: Found Auth-Type EAP
auth: type "EAP"
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 1
rlm_eap: Request found, released from the list
rlm_eap: EAP/md5
rlm_eap: processing type md5
rlm_eap
Re: help needed for debugging segfault
hi I've installed freeradius 1.1.0 from cvs and I'm doing EAP-PEAP using ntlm_auth for authentication. freeradius segfaults while sending the access-accept packet. In my first post someone instructed me to enable coredumps in freeradius and post the result. just a thought - wouldn't it be principally the same to run freeradius in the gdb and to backtrace (bt) after gdb catches sigsegv? ciao artur I've compiled freeradius using --enable-developer, set allow_core_dumps = yes in radiusd.conf and used ulimit to remove coredump filesize limit from my shell, but it seems freeradius still doesn't dump core. The radius server is a Debian testing box. The Wi-Fi accesspoint is a D-Link DWL-2100AP. Is there anything else I can do? Is this a freeradius issue or an OS issue? thanks - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Wireless Provisioning Service Protocol
hi Josh sorry to catch up so late on this. I mean EAP over RADIUS within a roaming consortium. A good example of one, which I'm involved in, is eduroam (www.eduroam.org). i took a look at this, it is mostly TERENA stuff for RADIUS... imho it only concerns the provider-provider interface and has nothing to do with WPS from my point of view. sorry, i don't see the point or the relevance of eduroam inter-provider agreements for the client provisioning. Most of the effort in WPS is expended in provisioning configuration stuff (SSID names, etc). But it's reasonably trivial for a roaming consortium to agree on these without requiring a protocol like WPS yes, it targets the user-provider interface. i'm sorry, but it is all but trivial to agree upon something like this in any realistic commercial roaming consortium. why? first of all, because roaming contracts are way too complicated and barely applicable for most of the current WISPs. second, because SSIDs etc. as almost anything in WiFi is not normative at all, ie. anybody can use whatever he wants and the problem is that is what the people currently do. change it a posteriori is too complicated. finally and most importantly, as a user you have no guarantee that the SSID you see represent the service you believe to get. and if you see two different SSIDs both belonging to commercial hotspots, you have to be able to find out service particularities _before_ connecting to the network. no aggrement can accomplish that for 802.1X based systems. and i won't even touch the platform integrity discussion... ciao artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Wireless Provisioning Service Protocol
hi Josh i know it's a bit OT but i think that it might still be interesting for some of us. I'll try and keep this brief, because it's a bit OT. WPS doesn't seem to offer anything particularly novel, besides a proprietary mechanism for configuring the Windows supplicant. imho it's as proprietary as PEAP is proprietary. or TTLS. or any other EAP method which is not (yet?) an RFC. and it does offer new possibilites. A much more sane approach, IMHO, is simple authentication-by-proxy as implemented by several roaming consortia. are we still talking about L2 security? if yes, can you provide some references on this? i don't know anything about it. Microsoft should put more effort into fixing their terribly broken supplicant, and stop trying to invent wheels... that's where we almost agree :-) MS really could and should improve their supplicant a lot, both in terms of correctness and in terms of usability. it's still a pain in the ass to use. the supported EAP methods are scarce. the API has changed several times since XP and the newest one is difficult to decipher... (greetings to Tom). however, i do expect from somebody as big as microsoft to do research, to invent stuff and to specify new things. btw, that's what the community was always critisizing MS before. they did hire some of the best scientists (look at their R&D stuff), so why shouldn't they invent new things now? ciao artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Wireless Provisioning Service Protocol
hmmm. i am not sure if the question is to be impressed. it is simply true that some signaling is necessary to allow user to choose a network (e.g. an operator). in usual hotspots you end up with a web page which can present you all the information you need (e.g. prices, names, available services, etc.) - however without any L2 security. but in 802.1X you have to first authenticate to be able to exchange any signaling. this is indeed insufficient e.g. for WISPs: how do you know that your authentication will work in a particular network? which authentication protocol should you use if it does not? what will you pay by accessing there? which service do you get? etc. etc. etc. all these things become terribly complicated. in fact, i've written a paper on that about two years ago... using something like TTLS/PEAP provides a tunnel which you can use to exchange any data with the operator's control plane, and that prior to IP. could you be more specific? regards artur On 5 Oct 2005, at 22:09, Josh Howlett wrote: I read the 132 page spec last night. Personally, I wasn't terribly impressed. josh. King, Michael wrote: Has any thought been given on adding the WPS (Wireless Provisioning Service) Protocol to FreeRADIUS? http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ randz/p rotocol/portal_wireless_provisioning_service_protocol.asp It sounds really cool in theory. From: http://www.microsoft.com/downloads/details.aspx? FamilyId=9ADF7496-0D50-4 138-848E-9BC810B83C01&displaylang=en With WPS technology, new and existing customers can connect to your Wi-Fi network without manual configuration of the computer or network connection. - List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Freeradius and Linksys WRT54GS
hi
i don't want to tell nonsense, but as far as I know, LEAP is not a pure
EAP type. the AP has thus to support it. and the WRT54 does not.
do not blame the WRT, blame LEAP and its design. and it has nothing to
do with 802.1X - standard 802.1X protocols should work with WRT54.
ciao
artur
Thierry wrote:
Hi,
I got a freeradius configured to handle LEAP authentication.
it works with a Cisco AP Cisco Airnet 1100:
client 10.0.0.1 {
secret = secret
shortname = apcisco
nastype = cisco
}
But it fail for linksys WRT54GS:
client 192.168.1.1
{
secret = secret
shortname = linksys
nastype = cisco
}
I tried different nastype :
With other or nastype commented, nothing happen after identity frames.
With cisco nastype, LEAP didn't finish, AP does not send the last
frame to respond to supplicant challenge.
Is there a specific nastype for Linksys ot this AP is bugged ?
I tried with another RADIUS (SBR/Windows) with the same comportment.
Do you know other AP than cisco ones that permit 802.1X successfully
with freeradius ?
Cordialement,
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: PEAP, Freeradius and Cisco AP 350
hi J Zakhar wrote: Having some trouble setting up PEAP with a windows XP workstation, a Cisco 350 AP (upgraded to IOS version 12.2), I am using the default XP Client to set things up. Many moons ago I had LEAP working great, the hard drive on this linux machine failed and it was time to reinstall. Not sure why i'm having such trouble with this. Mousing over the icon in my task bar Status: Validating Identity is all it ever says while trying to associate. I do however get prompted for my user name and password. Any advice/help would be much appreciated. unfortunately, imho Windows XP prompts for those before it starts the exchanges. from your log it seems that there is no error on the Freeradius side. FR sends out the Challenge, but the second message from the client (id = 36) looks to me as a repeat of the original Request (id 35). the contents of the EAP-Message are the same. thus it seems that your Windows client is not answering the challenge. Or the access point does not relay the challenge to the Windows client. difficult to say more from what you've given so far. you could try the following: - are you sure that you posted the complete log? - if yes, deactivate Server Validation in the Windows XP PEAP client (only for testing, activate it later) and re-start. see if the authentication gets to a further point. - if that does not change anything, take a look at the Ken Rosner's TLS FAQ (see www.freeradius.org). he describes how you activate EAP debug on Cisco 350 APs. log in into your cisco, activate the EAP Debug level 2 and see what happens - if it relays messages to the user machine. ciao artur ./radiusd -A -X Starting - reading configuration files ... reread_config: reading radiusd.conf Config: including file: /usr/local/freeradius/etc/raddb/proxy.conf Config: including file: /usr/local/freeradius/etc/raddb/clients.conf Config: including file: /usr/local/freeradius/etc/raddb/snmp.conf Config: including file: /usr/local/freeradius/etc/raddb/eap.conf Config: including file: /usr/local/freeradius/etc/raddb/sql.conf main: prefix = "/usr/local/freeradius" main: localstatedir = "/usr/local/freeradius/var" main: logdir = "/usr/local/freeradius/var/log/radius" main: libdir = "/usr/local/freeradius/lib" main: radacctdir = "/usr/local/freeradius/var/log/radius/radacct" main: hostname_lookups = no main: max_request_time = 30 main: cleanup_delay = 5 main: max_requests = 1024 main: delete_blocked_requests = 0 main: port = 0 main: allow_core_dumps = no main: log_stripped_names = no main: log_file = "/usr/local/freeradius/var/log/radius/radius.log" main: log_auth = no main: log_auth_badpass = no main: log_auth_goodpass = no main: pidfile = "/usr/local/freeradius/var/run/radiusd/radiusd.pid" main: user = "(null)" main: group = "(null)" main: usercollide = no main: lower_user = "no" main: lower_pass = "no" main: nospace_user = "no" main: nospace_pass = "no" main: checkrad = "/usr/local/freeradius/sbin/checkrad" main: proxy_requests = yes proxy: retry_delay = 5 proxy: retry_count = 3 proxy: synchronous = no proxy: default_fallback = yes proxy: dead_time = 120 proxy: post_proxy_authorize = yes proxy: wake_all_if_all_dead = no security: max_attributes = 200 security: reject_delay = 1 security: status_server = no main: debug_level = 0 read_config_files: reading dictionary read_config_files: reading naslist Using deprecated naslist file. Support for this will go away soon. read_config_files: reading clients read_config_files: reading realms radiusd: entering modules setup Module: Library search path is /usr/local/freeradius/lib Module: Loaded exec exec: wait = yes exec: program = "(null)" exec: input_pairs = "request" exec: output_pairs = "(null)" exec: packet_type = "(null)" rlm_exec: Wait=yes but no output defined. Did you mean output=none? Module: Instantiated exec (exec) Module: Loaded expr Module: Instantiated expr (expr) Module: Loaded PAP pap: encryption_scheme = "crypt" Module: Instantiated pap (pap) Module: Loaded CHAP Module: Instantiated chap (chap) Module: Loaded MS-CHAP mschap: use_mppe = yes mschap: require_encryption = yes mschap: require_strong = yes mschap: with_ntdomain_hack = no mschap: passwd = "(null)" mschap: authtype = "MS-CHAP" mschap: ntlm_auth = "(null)" Module: Instantiated mschap (mschap) Module: Loaded System unix: cache = no unix: passwd = "(null)" unix: shadow = "(null)" unix: group = "(null)" unix: radwtmp = "/usr/local/freeradius/var/log/radius/radwtmp" unix: usegroup = no unix: cache_reload = 600 Module: Instantiated unix (unix) Module: Loaded eap eap: default_eap_type = "peap" eap: timer_expire = 60 eap: ignore_unknown_eap_types = no eap: cisco_accounting_username_bug = yes rlm_eap: Loaded and initialized type md5 rlm_eap: Loaded and initialized type leap gtc: challenge = "Password: " gtc: auth_type = "PAP" rlm_eap: Loaded and initialized type gtc tls: rsa_key_ex
Re: concurrent TTLS and PEAP usage
Alan, Stefan replying to myself: using 'files' I've managed to make it work. the correct (working) configuration is: user_ttls FreeRadius-Proxied-To == "127.0.0.1", User-Password == "test_ttls" Session-Timeout = 3600 user_ttls EAP-Type != EAP-TTLS Auth-Type := Reject user_peap FreeRadius-Proxied-To == "127.0.0.1", User-Password == "test_peap" Session-Timeout = 3600 user_peap EAP-Type != PEAP Auth-Type := Reject that does exactly what I wanted. works like a charm for both PEAP and TTLS users. could somebody explain me how I can translate it into an SQL config? ciao artur Artur Hecker wrote: hi Alan hi Stefan thanks for your help. I think I understand the idea. however my problems are on the implementation level. two things are still not clear to me. 1. we use 'sql' and not 'files' (my fault i didn't mention it previously) and thus I don't see how I can add the line below to my user profile who already has things like User-Password ==..., etc. I tried adding user user_ttls into group TTLS and then using radgroupcheck like this: radgroupcheck: idUserAttributeopValue 2 user_ttls EAP-Type != TTLS 3 user_ttls Auth-Type:=Reject but then user_ttls gets rejected. how do I implement it with SQL? 2. we experimented with EAP-Type, but at least for PEAP as soon as we specify it somewhere in radcheck, PEAP breaks with a server error message saying that the client has sent a TLV rejecting the connection. Alan: like Stefan proposed I also thought about something like FreeRadius-Proxied-To, because i think that you proposal might not work as soon as the internal method starts for the user. Or don't external methods use EAP-Type? (still I am not sure how to define "conditions" in sql tables: if EAP-Type not this value, then add Auth-Type=...) ciao artur Alan DeKok wrote: Artur Hecker <[EMAIL PROTECTED]> wrote: user_ttlsEAP-Type != PEAP that however only prohibits the usage of PEAP for user_ttls while i would like to only enable TTLS for this specific user (which is not quite the same). user_ttls EAP-Type != TTLS, Auth-Type := Reject See the dictionaries for EAP-Type names. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: concurrent TTLS and PEAP usage
hi Alan hi Stefan thanks for your help. I think I understand the idea. however my problems are on the implementation level. two things are still not clear to me. 1. we use 'sql' and not 'files' (my fault i didn't mention it previously) and thus I don't see how I can add the line below to my user profile who already has things like User-Password ==..., etc. I tried adding user user_ttls into group TTLS and then using radgroupcheck like this: radgroupcheck: id UserAttribute op Value 2 user_ttls EAP-Type!= TTLS 3 user_ttls Auth-Type := Reject but then user_ttls gets rejected. how do I implement it with SQL? 2. we experimented with EAP-Type, but at least for PEAP as soon as we specify it somewhere in radcheck, PEAP breaks with a server error message saying that the client has sent a TLV rejecting the connection. Alan: like Stefan proposed I also thought about something like FreeRadius-Proxied-To, because i think that you proposal might not work as soon as the internal method starts for the user. Or don't external methods use EAP-Type? (still I am not sure how to define "conditions" in sql tables: if EAP-Type not this value, then add Auth-Type=...) ciao artur Alan DeKok wrote: Artur Hecker <[EMAIL PROTECTED]> wrote: user_ttls EAP-Type != PEAP that however only prohibits the usage of PEAP for user_ttls while i would like to only enable TTLS for this specific user (which is not quite the same). user_ttls EAP-Type != TTLS, Auth-Type := Reject See the dictionaries for EAP-Type names. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: multiple threads
hi Alan
ok, no i meant the daemon mode. sorry, my comment was a bit misleading.
it's just that i would expect FR to show every configuration token it
has read. and thread pool seems to be ignored in the debug.
It prints out the configuration it *uses*. It reads pretty much
anything from the configuration files.
e.g.
arthur {
france = yes
angleterre = no
}
will be read fine. :) But it won't be printed out in debug mode,
because the server isn't looking for it.
It makes the server a *lot* more forgiving, and easier to work with.
you know I remember a lot of users having _major_ problems with SCSI
because it was too forgiving for simple setups...
why not at least mentioning that the server has just ignored a
configuration token for whatever reason? e.g. ignoring thread_pool
because -X was given at the command line. might help someone to see that
his new config is not accepted. and don't you "patches are welcome" on
me :-)
but anyway, it was not at all my problem. you have already pointed out
the actual problem...
ciao
artur
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: concurrent TTLS and PEAP usage
hi [EMAIL PROTECTED] wrote: we naively try to specify EAP-Type == PEAP for user_peap and == TTLS for user_ttls but that breaks both methods (which seems normal since this EAP-Type definition is not correct for the internal EAP method which however uses the same user name). Why not almost just as naively do the check vice versa: If it's user_ttls and EAP-Type == PEAP, set Auth-Type explicitly to reject? what you are saying is that I should do something like this: user_ttls EAP-Type != PEAP that however only prohibits the usage of PEAP for user_ttls while i would like to only enable TTLS for this specific user (which is not quite the same). ciao artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
concurrent TTLS and PEAP usage
hi we have a Wifi 802.1X network with both TTLS and PEAP users (TTLS/PAP mostly for non-windows machines, PEAP/MSCHAPv2 for windows machines). (we also have TLS users, but that's out of scope). both work like a charm. however, we'd like to prevent PEAP accounts to log in with TTLS and vice-versa (that's a pure policy decision - one user profile should specify exactly one auth method). this works mainly because we store clear text passwords for both MSCHAPv2 and PAP. assuming e.g. two users user_peap with PEAP/MS-CHAPv2 and user_ttls with TTLS/CHAP, we would like to modify the profile of the user user_peap so he can't change the exterior method to TTLS/PAP and vs. note that we don't necessarily use exterior names (since e.g. MS Windows machines do not permit to specify an alternative user name for the exterior EAP tunnel). we naively try to specify EAP-Type == PEAP for user_peap and == TTLS for user_ttls but that breaks both methods (which seems normal since this EAP-Type definition is not correct for the internal EAP method which however uses the same user name). i thought about specifying tunneled attributes as check items. it turns out that FR does not show them in the log and I believe that these are not the same for the PEAP and TTLS anyway. thus the question to the list: how can I specify an "PEAP/MS-CHAPv2 only" user profile? how can i specify a "TTLS/PAP only" user profile? thanks artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: multiple threads
hi Alan >> context: on a Fedora Core 3 system (linux 2.6.9) I configured n=5 but FR would not start but one instance. also in the "radiusd -X" there is no notice of thread-pool config being read. > > > > FC4 uses a newer Linux kernel, which *correctly* shows only one > process via "ps", even when that process has multiple threads. ok. you are right. i found the thread info in /proc/$PID/status. > And "-X" means "don't start threads". See the "man" page. ok, no i meant the daemon mode. sorry, my comment was a bit misleading. it's just that i would expect FR to show every configuration token it has read. and thread pool seems to be ignored in the debug. thanks Alan. ciao artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
multiple threads
hi guys
has anybody ever noticed any difficulties of FR to launch multiple
initial threads? (thread_pool: start_servers n)
context: on a Fedora Core 3 system (linux 2.6.9) I configured n=5 but FR
would not start but one instance. also in the "radiusd -X" there is no
notice of thread-pool config being read.
does anybody have any ideas on that issue? how do I debug it? ("ldd
radiusd" shows libpthread correctly linked into the binary).
ciao
artur
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Radius, Radsec, Diameter [was: Silly question - secure Radius?]
apparently we do agree. thanks to Josh for his comment. just one thing: Alan DeKok wrote: Josh Howlett <[EMAIL PROTECTED]> wrote: I think the point the original poster was making was that Diameter allows arbitrary conversations between NASes and servers that are initiated by either party, via "applications", in an extensible manner. Yup. Which clients support diameter? I can't think of any. Until Cisco starts shipping diameter clients in their boxes, all of this discussion is wishful thinking. see? as i said: now you _started_ talking about God :-) ciao artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Radius, Radsec, Diameter [was: Silly question - secure Radius?]
hi just a small preamble: i perfectly understand your position and i do not expect you to start a diameter implementation tomorrow :-) for me it's merely a strategic discussion. Alan DeKok wrote: Artur Hecker <[EMAIL PROTECTED]> wrote: well, from my perspective the main arguments would be: ... Those are all nice arguments for diameter, and good reasons why the protocol was designed. But I keep coming back to: Where are the client implementations? There are few to none client implementations. perfect, apparently we've just closed the circle: i started this conversation by the statement "what are the manufacturers waiting for?" adding that we might be missing interesting opportunities (as a cause of manufacturers not integrating diameter). you asked which features i was talking about :-) and now you ask about devices. circle completed. according to this funny newsgroups discussion study, that's probably the point where we start talking about god (since we have reached the convergence). - reliability (especially for accounting) radsec from the NAS to the RADIUS server would solve this. only partly, i think, since the reliability of accounting depends on more than just on the reliability of transmissions. there are things to specify in the implementations, especially when we start talking about multi-party-accounting. you have to think about accountability, integrity and non-repudiation. the fact that accounting support is not obligatory in radius does not exactly help here. udp is generally not very handy when you want more control over the NAS, even if i understand the initial motivation to base radius on it. however, today you run in all those problems with NAT, session initiation in firewalled environments, reliability, security and so on. radsec solves this, too. that's probably true. but, citing you: where are the client implementations? do you know of any radsec-cacable 802.11 access point? that would interest me personally. and what is radsec anyway? it is not an RFC standard track and why would i implement proprietary solutions when the sense is to enable a multi-domain operation? - server-initiated messaging the strict client-server design of radius (imho amplified by the use of the conn-less UDP) does not allow for server-initiated commands such as "disconnect" or "force re-authorization on profile changes" (very important with PBM) Huh? See the "disconnect request" packets. Radclient even supports this! hmmm?? well... PoD is probably the ugliest hack ever. imho, PoD is not a solution but a proof that things have been badly overseen during the Radius-design and especially re-design phases. and anyway it only partially answers my question. disconnect is just ONE possible application. what about a complete PBM solution? - NAS management radius-typical fqdn/shared secret based security simply does not scale. it is too complicated to manage NAS in this manner and often results in network-wide radius passwords. radsec with per-NAS certificates solves this. true and same as above: not a standard, no NAS. - security with proxying in Radius proxies can modify packets. this is often not a good thing to do. diameter has a far better and more extensive support for TLS, especially for roaming scenarios. security might not be an issue in the way radius is typically used, but its security definitions are completely obsolete (strange md5-based hashing is not exactly the state of the art, and right now ipsec support is as improbable with NAS as diameter-support itself :-)). radsec doesn't support this, but there was a radius + kerberos draft which did. Recent opinions in the radius working group indicate that dropping this might have been a mistake. *provoke* why talking about drafts when we have a standard track protocol which supports this? :-) radius+kerberos: if it used used radius as a trusted third party, then it does not surprise me that it has been abandoned... ciao artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Radius, Radsec, Diameter [was: Silly question - secure Radius?]
hi alan sorry for the delay. you might be right. yet i think that we might ignore some opportunities which would be possible/supported by diameter. Like... what? well, from my perspective the main arguments would be: - reliability (especially for accounting) in every related implementation we always had to tweak around the timeouts etc. just because you can't be sure that the accounting-stop arrives correctly when the user is disconnected. especially in an environment with a lot of connects and disconnects, this results in "stalled" sessions which have to be explicitly treated and where the relation to the real network usage is principally lost. this is boring. udp is generally not very handy when you want more control over the NAS, even if i understand the initial motivation to base radius on it. however, today you run in all those problems with NAT, session initiation in firewalled environments, reliability, security and so on. - server-initiated messaging the strict client-server design of radius (imho amplified by the use of the conn-less UDP) does not allow for server-initiated commands such as "disconnect" or "force re-authorization on profile changes" (very important with PBM) - NAS management radius-typical fqdn/shared secret based security simply does not scale. it is too complicated to manage NAS in this manner and often results in network-wide radius passwords. - security with proxying in Radius proxies can modify packets. this is often not a good thing to do. diameter has a far better and more extensive support for TLS, especially for roaming scenarios. security might not be an issue in the way radius is typically used, but its security definitions are completely obsolete (strange md5-based hashing is not exactly the state of the art, and right now ipsec support is as improbable with NAS as diameter-support itself :-)). that's what bothers me personally, in this order. i think there are much more of those in the diameter RFC. i really believe that current usage produces demand in the same manner as demand influences the usage. using additional web-based "touches" to trigger server solicitations by the client is indeed quite ridiculous. I'm not sure what you're referring to here. well, we have seen a lot of implementations (especially in the hotspot management area) where people use HTTP from server to NAS to trigger radius-requests to be sent towards the server (!). it's nonsense. It shouldn't be too hard to write a radsec implementation. Ideally, it could leverage the TLS code in rlm_eap. that wouldn't be enough for roaming cases. ciao artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Radius, Radsec, Diameter [was: Silly question - secure Radius?]
you might be right. yet i think that we might ignore some opportunities which would be possible/supported by diameter. i really believe that current usage produces demand in the same manner as demand influences the usage. using additional web-based "touches" to trigger server solicitations by the client is indeed quite ridiculous. the main problem with radius is IMHO its client-server nature. it inherently lacks control. also TCP in dimaeter and defined TLS in proxy mode might be advantageous. ciao artur Alan DeKok wrote: Artur Hecker <[EMAIL PROTECTED]> wrote: well, that's not the point since diameter would be backwards compatible to radius... but i do ask myself what the manufacturers are waiting for. it could be at least an option. Diameter will be interesting ole when manufacturers ship millions of boxes with diameter. Why don't they? Let's look at what they need from RADIUS or diameter: 1) username/password authentication. Yup, RADIUS does this. 2) EAP->AAA for wireless. Yup, RADIUS does this. The nice thing about RADIUS is that it's so easy to implement. In contrast, diameter is 1000x more complicated than RADIUS, and it only solve .1% more problems than RADIUS. Diameter is not going to be widely deployed. Ever. see also "open diameter". it even does EAP... Not as many EAP methods as FreeRADIUS. :) Adding EAP-FAST to FreeRADIUS may not be too hard, either. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Radius, Radsec, Diameter [was: Silly question - secure Radius?]
Alan DeKok wrote: See "wire diameter", from Taiwan. I recall it's a student project, but it does give a minimal diameter server. But again, can you think of *one* client implementation of diameter? I can't. well, that's not the point since diameter would be backwards compatible to radius... but i do ask myself what the manufacturers are waiting for. it could be at least an option. see also "open diameter". it even does EAP... ciao artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Can do EAP/TLS, but not EAP/MD5
or simply put 'eap' as the last module in the authorize section. should be the same. Jefri bin Dahari wrote: It works. Thank you very much Vladimir. - Original Message - From: "Vladimir Vuksan" <[EMAIL PROTECTED]> To: "FreeRadius users mailing list" Sent: Friday, July 08, 2005 14:39 Subject: Re: Can do EAP/TLS, but not EAP/MD5 Jefri bin Dahari wrote: I have Freeradius running where wireless users authenticate using EAP/TLS. Now, I would like to use the same server to authenticate wired users using EAP/MD5 on Cisco switch 3750 but it doesn't work. The log shows it doesn't do EAP authentication as shown below. Attached is my eap.conf. You appear to be setting Auth-Type to Local. Check your Users file and see where the Auth-Type := Local or similar is getting set. Comment it out. Vladimir - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: MAC+EAP authentication
Alan, well, unfortunately not really. and most importantly: it does not assure the users use the known SOFTware to access the net. imho, hardware has never ever represented a problem so far. ciao artur On 6/14/05, Alan DeKok <[EMAIL PROTECTED]> wrote: > Artur Hecker <[EMAIL PROTECTED]> wrote: > > implementing EAP or MAC authentication, meaning that one of both would > > work, is a huge security hole and requiring both is useless since EAP > > authentication implicitly filters away everything unauthenticated... > > Doing *both* ensures that known users only use known hardware to > access the net. Sort of. > > Alan DeKok. > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: MAC+EAP authentication
i personally think that it's completely useless. implementing EAP or MAC authentication, meaning that one of both would work, is a huge security hole and requiring both is useless since EAP authentication implicitly filters away everything unauthenticated... (even if i understand that might be necessary for current WiFi phones, etc., please be aware that under linux you can actually change the MAC address with one command...) ciao artur On 6/13/05, Alan DeKok <[EMAIL PROTECTED]> wrote: > "Jefri bin Dahari" <[EMAIL PROTECTED]> wrote: > > I plan to implement simultaneous MAC+EAP authentication for my wireless > > users. From my observation, Freeradius can only do either MAC or EAP but not > > MAC and EAP authentication. Can somebody gives me some hints on how to do > > that? > > It can do both. EAP is authentication, MAC checking isn't really > authentication. > > What are you seeing in RADIUS packets, and what do you want to happen? > > Alan DeKok. > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Free RADIUS for WLAN - Problems?
hi
- What are differences between "unicast key" and "multicast/global key".
If unicast key is used
for encrypting per-client data and if I have 20 client, does that mean
Access Point must hold all
of course, since the communications are encrypted with a different key
per client. otherwise your cell neighbors could read your data.
20 per-client unicast key? And if multicast/global key is used for
encrypting multicast/broadcast
traffic, does that mean we have to pre-configure the key in Access Point?
when it gets down to details, then it gets a little bit nasty, since
strictly spoken before 802.11i there wasn't any real standard for that.
talking about 802.11i, the answer is NO. the multicast key is chosen
randomly by the access point for the first client and is delivered to
the client by the access point using a key encryption key for any
subsequent client.
- Can someone explain me about "4-way handshake" and how a client
derives 128-bits key for
Encryption and 64-bits key for MIC.
yes, the IEEE 802.11i standard. please read the security section or look
on the web for 802.11i 4way handshake. i'm sure you'll find enough
information.
- I want to authenticate my clients with ComputerName\\UserName and i
configured my
radiusd.conf like below:
realm ntdomain {
format = prefix
delimiter = ""
ignore_default = no
ignore_null = no
}
Is it right? Is it neccessary to care lowercase or upercase in ComputerName?
ahem. i think that you could do it this way, but it is not necessary.
the realms are primarily used for relaying requests to other servers. if
you just want a naming convention, you could probably directly store
these names in a database.
- And I have a problem with my XP client: after the first successful
authentication, when I
disconnect and reconnect, Instead I must enter my username and password,
It automatically
connect without a login prompt.
you mean with PEAP/MS-CHAPv2? yes, Windows XP stores the credentials in
the registry.
http://support.microsoft.com/default.aspx?scid=kb;en-us;823731
ciao
artur
--
Artur Hecker
WaveStorm SARL
WaveStorm Support: [EMAIL PROTECTED]
http://www.wave-storm.com
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FreeRADIUS + 802.1x (WPA) + WinXP + smbpasswd
would you mind writing down a small doc with your experiences?
i'm sure it would be nice to know for everyone.
Jim Seymour wrote:
"Alan DeKok" <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] (Jim Seymour) wrote:
Clarification: Giving the server ADMINNB\jseymour works. Giving it
just "jseymour" does not.
Because the regex on the line above doesn't match. So, do:
DEFAULT User-Name =~ blah
My-Local-User-Name = "%{1}"
DEFAULT
My-Local-User-Name = "%{My-Local-User-Name:-%{User-Name}}"
Boy, I sure am missing some of the more obvious ones, aren't I?
Okay, that worked. Thanks for all the help, Alan. And all you
others, too!
Jim
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Accouting Problems
sorry for this response but the failure in that specific scenario is very unlikely to be on the server. the Session-Timeout value and the Accounting events have to be respected/generated at the client. so, if you don't have the Accounting Stop for a disconnected user, then the client is no good. if the client does not follow the Session-Timeout which it has previously received in the Access Accept, then, once again, it's the fault of the client. try to ask ChilliSpot or Linksys people - wherever you are sending the Accept to. ciao artur Sebastian Steinhauer wrote: Hi. I'm working an wireless network for our local city. I'm using freeRadius 1.0.1 on a Debian server and Alchemy 6.0 with ChilliSpot on Linksys accesspoints. Everything's working fine but I've a little problem with the accouting function on freeRadius. Everything (including the radacct) is stored in a MySQL database. Every user is in a group with following attributes in radgroupreply: Session-Timeout := 10800 Idle-Timeout := 900 Now I've following problem. If a user disconnects without loggin off from the system over the CilliSpot Logoff-URL the user will be kept online (AcctStopTime = 0) in the radacct. Even the Session-Timeout seems not to work properly. May it be I've forgotten a special setting or an another attribute? But I had an interesting experience. A Session-Timeout about 5-10 minutes seems to work, but the current Session-Timeout doesn't work. Perhaps someone can help me out...that would be fine. If you need more information please ask for them, I'll give it to you. Thankyou, Sebastian Steinhauer - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Zertifikate für WinXP Supplicant
die sind glaube ich in den neuesten releases von freeradius bereits vorhanden, oder? schau mal im verzeichnis rum... weiss nicht wo. ciao artur PhonTom wrote: Liebe Leser! Ich habe Freeradius auf CentOS 4.0 laufen und bekomm mit meinem openssl Keine Zertifikate erstellt. Pfade usw. habe ich schon geprüft, jedoch hat das ganze auch nicht funktioniert. Kann mir vielleicht jemand einfach ein CA root Zertifikat plus das Server und 1 Clientzertifikat Erstellen, damit ich das ganze zumindest testen kann? Ich wäre dafür sehr dankbar, da ich mir gar nicht mehr sicher bin, obs am openssl liegt? Lg Thomas - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: WinXP EAP-TLS: Zertifikat
hallo nur ein kleiner versuch: ueberpruef mal nach dem installieren, ob das zertifikat tatsaechlich vorhanden und gueltig ist (nimm mmc, Snap-In hinzufuegen, zertifikate auswaehlen, hinzufuegen, ok. windows wird fragen, welches konto gemeint ist; du waehlst das private aus, wenn du das private meinst bzw. maschinenkonto, wenn du dieses meinst). dann ueberpruefen: 1. ob das client-zertifikat unter eigenen zertifikaten installiert ist und tatsaechlich einen privaten schluessel enthaelt. 2. Vertrauenswuerdige zertifizierungsstelle die das erstere signiert hat ebenfalls ein Zertifikat hat, und zwar im entsprechenden Kontainer. 3. dass beide gueltig sind und windows bei der ueberpruefung nicht mosert. ciao artur Thomas Schleindl wrote: Hallo, ich habe einen Freeradius Server der letzten Version unter CentOS 4 laufen. PEAP funktioniert wunderbar, auch die überprüfung des Serverzertifikates passt soweit. Im nächsten Schritt möchte ich gerne den Client mittels Zertifikat anstatt usr/pwd identifizieren. Leider gibt Windows immer die Fehlermeldung "Es wurde kein Zertifikat gefunden, um Sie am Netzwerk anzumelden" aus. Ich habe jedoch das cert-clt.der bzw. cert-clt.p12 schon zigmal installiert und auch darauf geachtet, dass die Verwendung als Clientzertifikat markiert ist. Hat jemand hierzu einen Tip bzw. Link zu einem HOWTO?? Ich arbeite mit WinXP SP2 und einem HP Switch im Testaufbau. thx Thomas - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: About client web authentication
Nurul probably means client isolation. Nurul, your issues are not really related to freeradius. You can authenticate over whatever you want to freeradius. However, that's not your point. For what you want to do, you need to setup the access controller which is just another NAS in AAA slang. WLAN client isolation is a purely NAS internal functionality. You have to do that at the access point (a L3 firewall can not achieve that since the packets are forwarded on L2). So, take a look at hotspot-like access controllers which provide captive portal functionality. There is "nocat" e.g. but a lot of others do the same. There are also a lot of commercial products. hope that helps. if you need more help, try to ask offline. ciao artur Marcin Jessa wrote: I have no idea what you are talking about. If you mean that WLAN users will be able to talk to eachother after authentication then yes, that's the whole point of opening the network. You need to describe your network first. On Thu, 10 Mar 2005 15:56:36 -0800 "Nurul Faizal M.Shukeri" <[EMAIL PROTECTED]> wrote: Tq 4 ur response But if I do this, wlan user still can access each other. How to protect that? Is that mod_auth_radius that I'm looking for? TQ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marcin Jessa Sent: Wednesday, March 09, 2005 6:31 PM To: freeradius-users@lists.freeradius.org Subject: Re: About client web authentication You need some kind of hotspot server like routeros or staros. Or you can do that with Squid and custom firewalling rules to open connections from i.e. PPTP authenticated users. On Thu, 10 Mar 2005 09:28:01 -0800 "Nurul Faizal M.Shukeri" <[EMAIL PROTECTED]> wrote: Hi everyone., Can anyone explain how to deploy client web authentication. I'm using freeradius to authenticate wireless user. For the time being I'm just installed Aegis or 802.1X built in windows to be supplicant. Anyone, plz help me . TQ very much - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Regards, M. Jessa Software developer/System Administrator http://www.yazzy.org - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: PEAP and "fatal unknown_ca"
8af153a26274412e8e63816ecaa5bc997bf18ffaef66d42b98c0deb6f4db1ba0b0 150203010001a381f33081f0301d0603551d0e04160414552260d6dd4cebade9a0adacf4733a bee5640ca33081c00603551d230481b83081b58014552260d6dd4cebade9a0adacf4733abee5 640ca3a18191a4818e30818b310b300906035504061302555331123010060355040813095465 6e6e657373656531123010060355040713094f616b205269646765310d300b060355040a1304 53414943310f300d060355040b13064e4149534d43311830160603550403130f4e4153565231 3820526f6f74204341311a301806092a864886f70d010901160b EAP-Message = 0x746d68406e617376723138820900aa339d443f523340300c0603551d13040530030101ff30 0d06092a864886f70d010104050003818100bd318788d5775b1446536c2cabe5031b72131346 177a421c930f4ffbf36ba1d516789335f29e984575ab736f350adecf1e437fc5f2a4b3be0a03 6c90abc5ac4689237bafc1cf0130ede334bacec4689fbacd52cb8f7c6412efa28c96827164ce 8f6dcbb4d8d09c19e8fdc71cad56d2d665e02c6dfdaab49b83fdc2de3d6e474c160301010d0c 0001090040d3706dbd315a1e6c6d31d7360a14069120fd6cd0de306332ac00d88280dbd81175 f1462cee6e4c0e58aa60e0190906edbf214e2bb7024043da0b66 EAP-Message = 0xba7b8c5dc300010500404e9adcd06469e95f46852f53d7befb50802a71644dd633a501f6b4 82f01857af8a6de4056b27b1a9cbc8c9fc42a67354f698201690fd1d8bb8b58d415690d0c700 80d7c0706283d95cd56c5448bc3450fc6cbc7b63366fee4fbe37b5346453c42c2aa3eb857afe a3ba215cecfaa471487fe7363549984a4b850b7e80601daa5c23e1baaaf727964cca749eb0c1 40d7e0967915c072c264ed51930825ab6020d45562b1c2e947933ef885759c0ac83611621d6c 0b31c0f9cc885fb587317227c972eb16030100040e00 Message-Authenticator = 0x State = 0x36cdeb1e4af1060e78512ffdc9c31264 Finished request 2 Going to the next request Waking up in 6 seconds... rad_recv: Access-Request packet from host 10.0.1.3:21645, id=152, length=191 User-Name = "atkinsondu" Framed-MTU = 1400 Called-Station-Id = "000f.9060.c140" Calling-Station-Id = "0040.96a2.8ef1" Cisco-AVPair = "ssid=eap-only" Service-Type = Login-User Message-Authenticator = 0xfeb6cd762306cd1a886420d036082cc8 EAP-Message = 0x02040011198715030100020230 NAS-Port-Type = Wireless-802.11 Cisco-NAS-Port = "369" NAS-Port = 369 State = 0x36cdeb1e4af1060e78512ffdc9c31264 NAS-IP-Address = 10.0.1.3 NAS-Identifier = "wifi-ap1" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 3 modcall[authorize]: module "preprocess" returns ok for request 3 rlm_realm: No '\' in User-Name = "atkinsondu", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "ntdomain" returns noop for request 3 rlm_realm: No '@' in User-Name = "atkinsondu", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 3 rlm_eap: EAP packet type response id 4 length 17 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 3 modcall: entering group group for request 3 rlm_dbm: try open database file: /opt/local/etc/raddb/database/users rlm_dbm: Call parse_user: sm_parse_user.c: check for loops Add atkinsondu to user list rlm_dbm: User not foud in database Remove atkinsondu from user list sm_parse_user.c: check for loops Add DEFAULT to user list rlm_dbm: User not foud in database Remove DEFAULT from user list modcall[authorize]: module "dbm" returns notfound for request 3 modcall: group group returns notfound for request 3 modcall: group authorize returns updated for request 3 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 3 rlm_eap: Request found, released from the list rlm_eap: EAP/peap rlm_eap: processing type peap rlm_eap_peap: Authenticate rlm_eap_tls: processing TLS rlm_eap_tls: Length Included eaptls_verify returned 11 rlm_eap_tls: <<< TLS 1.0 Alert [length 0002], fatal unknown_ca TLS Alert read:fatal:unknown CA TLS_accept:failed in SSLv3 read client certificate A 24317:error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca:s3_pkt.c:1052:SSL alert number 48 24317:error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure:s3_pkt.c:837: rlm_eap_tls: SSL_read failed in a system call (-1), TLS session fails. In SSL Handshake Phase In SSL Accept mode rlm_eap_tls: BIO_read failed in a system call (-1), TLS session fails. eaptls_process returned 13 rlm_eap_peap: EAPTLS_HANDLED rlm_eap: Freeing handler modcall[authenticate]: module "eap" returns reject for request 3 modcall: group authenticate returns reject for request 3 auth: Failed to validate the user. Delaying request 3 for 1 seconds Finished request 3 Going to the next reque
Re: Radius for 802.1X and TKIP
hi TKIP is the encryption method used on the wireless link. radius is designed to be independent of the access technology used by the NAS. in other words, TKIP is something which is not known to the radius server - by design. the radius server will - if available - provide the NAS (802.11 access point in that case) with the "raw" key material. however it is up to the NAS to derive the necessary keys from it. you configure the NAS to use TKIP on the link. freeradius is automatically configured in a way that will derive and attach key material to the access-accept message sent to the solicited NAS. you can see the MPPE-*** attributes in the access-accept message in the full log (radiusd -s -X) ciao artur Dani Camps wrote: I want to set up a secure wlan using EAP-PEAP as authentication method and Radius as a authentication server, in the AP I choose TKIP encryption, but I think TKIP needs to renew the keys used, and I think is the Radius server the one that has to create the keys and pass them to the AP, is this true ? In that case how to configure Radius to use TKIP ? Any of you have experience in this set up, wlan with EAP-PEAP authentication in a Radius server and using TKIP for encryption ? Thanks ! __ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
rapid question on PEAP version
hi i just looked in the doc directory, the source code and a bit on the web and could not find any recent info on which version of EAP-PEAP is supported by freeradius. from what i've found till now, only PEAPv0 with MS-CHAPv2 is supported (this however dates back to June 2004). has it by any chance been updated since? most notably, is the so-called cryptobinding (PEAPv2) already implemented? and when we are already in there, perhaps somebody knows the same answers for TTLS (cryptobinding has been recently added to the I-D) and the clients: xsupplicant, XP SP2, Alfa-Ariss, etc. moreover, for the tunneled methods, it would be nice to know client- and server-side inner method limitations. a small summary would be just perfect. thanks artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
cisco ACS vulnerability
FYI: EAP-TLS vulnerability in cisco ACS http://www.cisco.com/warp/public/707/cisco-sa-20041102-acs-eap-tls.shtml ciao artur PS it's a bit out of topic, but well, they also have their problems :-) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: research project
hi as far as I know, german 1&1 division has been using freeradius for years for the access control of their xDSL users. however, i'm not up to date... ciao artur Henning,Rhiannon Michelle wrote: Do you mind if I ask which radius server you were using before? How many users are you currently supporting per server? Wired and wireless users? Thanks. Rhiannon Henning -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graeme Hinchliffe Sent: Tuesday, October 12, 2004 9:38 AM To: FreeRADIUS list Subject: Re: research project If you want some "we use freeRADIUS and love it" style blurb to slap on the freeRADIUS site, give me a shout I would be happy to oblige. Since we (Zen Internet) moved over to freeRADIUS a lot of headaches have gone, and people are authing faster than ever before :) We arn't a new startup either - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Q about debugging output
hi Now take the EAP-Message: 0x 02 02 000d 01 74 65 73 74 75 73 65 72 hex code id length data (9 octets) Splitting done right? If so, code, id, and length are consistent with rlm_eap: EAP packet type response id 2 length 13 But why are there only 9 bytes of data -- I expect 13? Is it truncated in some way? not at all: the length is not the length of the data field but of the whole packet: 9 data + 2 length + 1 id + 1 code = 13. according to RFC3748: Length The Length field is two octets and indicates the length, in octets, of the EAP packet including the Code, Identifier, Length, and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and MUST be ignored upon reception. A message with the Length field set to a value larger than the number of received octets MUST be silently discarded. hope it helps artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FreeRADIUS - 802.1x WPA-TKIP, WPA2-AES settings
add to it: forward the DHCPDISCOVER to the DS if no internal table entry for this MAC is found. yapp, that would be even very easy to integrate. but i don't think that _any_ AP does that. ciao artur Damjan wrote: just for the case: no, it is NOT possible to assign IP addresses by 802.1X; you have to do DHCP after the authentication (yes, it is strange). A clever AP could support this: 1. Serving DHCP to the wireless netowork only 2. Getting the Framed-IP-Address from the radius Access-Accept, and putting it in a internal table (MAC -> IP) 3. Serving that exact IP via DHCP when the subsciber asks for a lease. I don't know of an AP that does that, though. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Q: Allowing 1 EAP type per SSID with 1 AP and 1 Radius Server.
hi 1. in AP 12 you can assign an authentication server per SSID. from here on, you could have two different servers, one for LEAP and the other for EAP/TLS. Can loopbacks be used on a FreeRadius server so that it control the EAP type allowed based on the targeted interface? Not needed if I can get the below to work. i don't think so, but what would it be good for? just start two radius servers on different ports and configure the SSID parts in the APs appropriately. it's not difficult and you can really be sure that your LEAP users land on your LEAP enabled FR while your TLS users use your TLS enabled FR. you can even enforce the immediate denial in the case where LEAP is used on the TLS server, etc. 2. Cisco APs do provide SSID information in the incoming requests. this is put in a Cisco VSA. if you put your server into debug mode and look at the incoming requests, you'll see the SSID appearing as something like Cisco-VSA = "ssid=my_ssid" Not on mine. I'll try an IOS upgrade. oh, ok, that's strange. either it's an option (but i've never seen a cisco AP without that VSA in its request so it should be ON by default and you deactivated it once - reset to factory defaults should do the trick) or it is really a IOS version issue. and finally, if you have a direct wire to a Cisco Product Manager, please kick his ass from my part convincing him of the need to finally correct the accounting behavior of the newest AP12 IOS release. in my case, accounting does not contain AcctInputOctets nor AcctOutputOctets. =) If you e-mail me directly with the details I'll be glad to. ok - as soon as possible :) ciao artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Q: Allowing 1 EAP type per SSID with 1 AP and 1 Radius Server.
patrick, if i understand your problem correctly, you want to have a different EAP type per SSID using the cisco APs of the 12 series. there are basically two major possibilities to do so, independently of what has been said before: 1. in AP 12 you can assign an authentication server per SSID. from here on, you could have two different servers, one for LEAP and the other for EAP/TLS. 2. cisco APs do provide SSID information in the incoming requests. this is put in a cisco VSA. if you put your server into debug mode and look at the incoming requests, you'll see the SSID appearing as something like Cisco-VSA = "ssid=my_ssid" you can process this line in freeradius and treat it differently depending on the SSID, as has been explained by Alan. now for the MAC-address format: look at the config of the AP 12. you can change the MAC address format, AP 1200 supports cisco-format, IETF format (see your email) and an unformatted char string. the IETF format however does not contain the SSID. and finally, if you have a direct wire to a Cisco Product Manager, please kick his ass from my part convincing him of the need to finally correct the accounting behavior of the newest AP12 IOS release. in my case, accounting does not contain AcctInputOctets nor AcctOutputOctets. ciao artur Patrick Mowry (DHL US) wrote: Thanks Michael, The AP (Cisco 1200, IOS 12.2(13)JA1) formats the Called-Station-ID as "0007.50d5.". I'll forward the RFC information to the product Manager to see if this can be added to the next release. There is another feature being added to the IOS software for the APs to address my issue, but it is not even in beta yet. Thanks again, -Patrick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Griego Sent: Wednesday, September 08, 2004 11:16 AM To: [EMAIL PROTECTED] Subject: RE: Q: Allowing 1 EAP type per SSID with 1 AP and 1 Radius Server. RFC3580 section 3.20: 3.20. Called-Station-Id For IEEE 802.1X Authenticators, this attribute is used to store the bridge or Access Point MAC address in ASCII format (upper case only), with octet values separated by a "-". Example: "00-10-A4-23-19-C0". In IEEE 802.11, where the SSID is known, it SHOULD be appended to the Access Point MAC address, separated from the MAC address with a ":". Example "00-10-A4-23-19-C0:AP1". If you AP is compliant with this RFC, look in the Called-Station-Id attribute. --Mike On Wed, 2004-09-08 at 12:52, Patrick Mowry (DHL US) wrote: "Patrick Mowry (DHL US)" <[EMAIL PROTECTED]> wrote: My understanding of Wireless 802.1x supports boils down to the AP passing the EAP authentication to the backend radius server after the initial EAPOL, but the actual EAP type used is up to the supplicant. Yes, but the server has to agree. I would like to use EAP-TLS for an SSID for wireless LAN access, and LEAP (no other choice :( ) for wireless phones. But if the SSIDs are configured on all APs, All APs point to a single FreeRadius Backend configured for TLS, LEAP and PEAP; how do I prevent a compromised LEAP account from being used to access the SSID supposedly secured by EAP-TLS? Is the SSID in the RADIUS packet? If not, you can't key off of SSID to force EAP types. No, nothing in the access-request, including NAS-PORT, seem to correlate to a SSID. Watching the logs with radiusd -X -A I do not see a field I can key off of to limit the EAP type allowed. In the "users" file, you can do: bob EAP-Type := Cisco-LEAP to force that user to use a specific EAP type. See share/dictionary for the known VALUE's of the EAP-Type attribute. Alan DeKok. But since the AP does not pass SSID info, nor interfere with the type of EAP Allowed per SSID, it seems I'm SOL. I'll more this to another group, but is anyone aware of an AP that does either of the above? I'll investigate further into Cisco 1200 and the Symbol WS5000 if Anyone is interested. Alan, Thanks again for your help, -Patrick - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FreeRADIUS - 802.1x WPA-TKIP, WPA2-AES settings
hi However, how to direct or tell the authenticated Radius client/station go to get the IP address from the DHCP server, in other words, is in the RADIUS server where to indicate the DHCP server IP address (or point to my DSL router 192.168.1.1). no. radius is used till to the point when the authenticating station gets access to the network. if it helps, you can compare it to a (somehow controlled) plugging into the network plug: from the point you plug a station in, it is up to the station to send DHCPDISCOVER messages and to interpret the offers from the servers. in the case of 802.1X and radius, the station does exactly the same as it would do if you just plugged it in. now, if you wanted to make a logical link between the authenticated station/user and the assigned IP address, you would have to go farther (e.g. execute a script every time a new station connects which reconfigures your DHCP server to assign a chosen IP address to the seen MAC address etc.) ciao artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FreeRADIUS - 802.1x WPA-TKIP, WPA2-AES settings
hi Are there any instruction, step-by-step on how to build the RADIUS server for WPA and WPA2 (802.11a/b/g). yes, there are. today, it should work "out of the box" (well, there is no box, but still). the good news from the pov of the radius server is that all these things you mentioned are transparent for it; the AP has to do a/b/g and WPA/WPA2 from the keying information received from the server (that may be kind of half true, because at least WPA2 is not yet released and thus half ready). in any case, if you have an AP you bought recently, it should work with FR directly. And would there be possible to install the RADIUS server separate from DHCP server? if yes, how to? hmm? yes, the two instances have no relation to each other whatsoever. you install the first and then the second. just for the case: no, it is NOT possible to assign IP addresses by 802.1X; you have to do DHCP after the authentication (yes, it is strange). the Client is Windows XP, which has support for 802.1x client. true, and it should work, PEAP/MS-CHAPv2 and TLS are supported by FR. ciao artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: PEAP + per session WEP
ok, whatever a PEAP request means in the original mail :-) it would be crazy to constantly deliver the same value, what would it be good for? that's why it's called "dynamic WEP"... ciao artur Alan DeKok wrote: Artur Hecker <[EMAIL PROTECTED]> wrote: the values in MS-MPPE-Recv-Key and MS-MPPE-Send-Key change in every PEAP request... what do you mean by this statement? these attributes are only present in the Access-Accept message sent by the radius server to the NAS. He means that at the end of every PEAP session, the keys are unique. They're supposed to be. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: PEAP + per session WEP
hi When you say "freeradius delivers the necessary keying data", do you mean these two following keys? MS-MPPE-Recv-Key = 0xc0eb6159c1ccc924b524d39c21f3c41588c60dd41945a1480b9119ef809c3060 MS-MPPE-Send-Key = 0xd9e5ca0d05d2430c4e8abea402d47d742bf80ff361945a76f0d0b14e6b84a656 that's exact. the values in MS-MPPE-Recv-Key and MS-MPPE-Send-Key change in every PEAP request... what do you mean by this statement? these attributes are only present in the Access-Accept message sent by the radius server to the NAS. ciao artur it's a function of your access point. freeradius delivers the necessary keying data. your access point (authenticator) has to use it to produce the wep keys. similarly, your wireless client (supplicant) produces its keying data and the both latter can negotiate the wep keys together. thus, _both_ link partners have to support the dynamic wep keying and be compatible in this regard. under ms-windows you say "the key is delivered by the network" or something like this in the wireless network settings. ciao artur Ivan Hernández Serrano wrote: Hi, I am using freeradius 1.0.0, at this moment it uses PEAP and everything goes fine. Now, I would like to generate a dynamic WEP key per client, but I have no clue how to do it, I has been searching in the mail archives, and in the docs without any results. I will appreciate if anyone can either give me a hint or give me the location of some references. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: PEAP + per session WEP
it's a function of your access point. freeradius delivers the necessary keying data. your access point (authenticator) has to use it to produce the wep keys. similarly, your wireless client (supplicant) produces its keying data and the both latter can negotiate the wep keys together. thus, _both_ link partners have to support the dynamic wep keying and be compatible in this regard. under ms-windows you say "the key is delivered by the network" or something like this in the wireless network settings. ciao artur Ivan Hernández Serrano wrote: Hi, I am using freeradius 1.0.0, at this moment it uses PEAP and everything goes fine. Now, I would like to generate a dynamic WEP key per client, but I have no clue how to do it, I has been searching in the mail archives, and in the docs without any results. I will appreciate if anyone can either give me a hint or give me the location of some references. Thanks in advance, ivan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Opinions on WLAN roaming
hi actually, the WISPr BP by the Wi-Fi Alliance is not a standard, it's explicitly marked as non-normative of any kind and called "best practice for WISP roaming". since Wi-Fi alliance still considers 802.1X as not wide-spread enough, they did not include it in their current recommendations but they also state that they will do it once (which is not suprising given 802.1X is included in WPA and 802.11i). since i think that WLAN without L2 access control is quite mindless in the general case, you should look at the 802.1X for roaming. now, 802.1X typically uses (but does not require) radius. additionally, since you are asking this at the freeradius list, i would say that WISP roaming basically equals radius roaming. now, the development is quite straightforward: make it be radius proxying and define additional attributes (if needed) for SLA purposes etc. divers optimizations are possible e.g. to avoid O(n^2) number of security associations, to avoid any common databases, to minimize the interdomain traffic and sim. to keep the high reactivity of the system (propagation of the changes applied to a user profile) in this scope, etc etc etc. i think some work has been already done on it and a lot is known from the basic radius management in a production environment. ciao artur Thor Spruyt wrote: I actually mean roaming between WISPs, like GSM roaming. I don't understand why they have called AP handover also roaming, it always confuses people :) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Securing a wireless network with users database in LDAP (Win and Mac OS-X clients)
hi But will PAP be supported by supplicants running on Windows and Mac OS-X ? If you are going to use EAP-TTLS you must use the SecureW2 client since windows do not support EAP-TTLS. SecureW2 supports PAP so you should be fine. I have no idea about MacOS X though since it's a unix flavor maybe Xsupplicant can work on it (Xsupplicant supports EAP-TTLS). apparently, xsupplicant works, but with some modifications. however, since Mac OS X (10.3++) there is an integrated client which is more convenient and does support TTLS. http://images.apple.com/macosx/pdf/Security_in_Mac_OS_X.pdf, page 8 ciao artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 802.1X HOWTO (draft)
probably because a big company in redmond is responsible for the latter. but i have nothing against it. ciao artur Troy Davis wrote: Just from a very newbie's put of view why do you briefly touch on setting up a UNIX client and not a windows client Regards Troy - Original Message - From: "Lars Strand" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, July 23, 2004 8:02 PM Subject: Re: 802.1X HOWTO (draft) On Thu, 22 Jul 2004, Artur Hecker wrote: 1. the document needs a quick native speaker review. guys? The tldp.org have a language review before it is published ;-) 2. remove the repetitions of the form "how 802.1X works". Fixing it later today. 3. add links to XSupplicant and FreeRadius in the abstract. Done. 4. Authenticator config: since the images you include are HTML pages, you can reduce the overall document size using the trick used in e.g.: http://www.freeradius.org/doc/EAP-MD5.html (not important) I'm writing the HOWTO in DocBook XML, and can then later be converted to html, pdf, ... - I don't belive docbook has support for inline html.. overall I think images are better. also add an image on EAP usage configuration (you only have the radius related config, where is the SSID-related config?) Will add that later today. 5. WPA / RSN: stop confusing people even more :-) try this: TSN = TKIP+WPA/RADIUS = WPA(1) RSN = CCMP+WPA/RADIUS = WPA2 Ok - added ;-) basically, if you really want to explain stuff instead of just saying "do that, do this" you can add an explanation divided in several sections which are to consider: - network access control (here: always 802.1X) - authentication method (with 802.1X EAP is implied) - link layer encryption (TKIP, CCMP, WEP, etc.) - backend server (EAP-capable RADIUS server implied by 802.1X) - magic glue :-) i.e. all the conventions on how and when to derive what and from what and how often and how to transport all this between AS/A etc., This requires some major restructuring - will look into it later today.. 6. in the Xsupplicant section: Configuring Xsupplicant, point 5: are you sure that "/sbin/iwconfig eth0 mode managed essid testnet enc off" will let you associate with networks mandating WEP or TKIP usage? have you tried that with an access point which requires L2 encryption? my card would not associate to WEP-networks unless i do "iwconfig eth= key 0x0" or provide some bogus key. No - I've just done authentication - no dynamic WEP. Others have requested this as well - will look into it later today. I'm a little uncertain here: xsupplicant claims to have support for dynaic WEP (which I'll try later), but what about WPA/802.11i? Is there no other way than to use HostAP? Does anyone have any experience to share by using PEAP-MSCHAPv2 with xsupplicant and dynamic WEP (to get me started)? I'm a little reluctant to use HostAP, since it will increase the HOWTO and the complexity even more... WPA and 802.11i support is beeing worked on for Xsupplicant.. also, why not adding "allmulti" to the "ifconfig eth0 up" directive? Why? To let the interface recive new session/broadcast keys? otherwise it looks good to me Thanks for the feedback! -- Lars Strand GnuPG/PGP Key: http://www.gnist.org/~lars/pubkey.asc ID: 972F4325 "The Internet? Is that thing still around?" -- Homer Simpson - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 802.1X HOWTO (draft)
hi lars I'm writing the HOWTO in DocBook XML, and can then later be converted to html, pdf, ... - I don't belive docbook has support for inline html.. overall I think images are better. ok :-) I'm a little uncertain here: xsupplicant claims to have support for dynaic WEP (which I'll try later), but what about WPA/802.11i? Is there no other way than to use HostAP? actually, xsupplicant can be seen as almost independent of WPA, except for the derivation and the PSK mode. in any case, you will need a tool which will configure the wireless card. imho, wireless-tools currently do not support WPA (you can't choose the algorithm, etc.) Does anyone have any experience to share by using PEAP-MSCHAPv2 with xsupplicant and dynamic WEP (to get me started)? yes: 1. radius server - the same which you explain, nothing changes, freeradius does it automatically (also works with WPA) 2. authenticator: activate L2 encryption, activate open authentication, activate "require EAP" for the open authentication. since "dynamic WEP" is not really a full definition, this can vary a lot depending on the access point: some will require you to set an initial WEP key, the others will require to set a broadcast WEP key, etc. e.g. Cisco APs will use the host key as the WEP key directly, meaning that there won't be any key rotation during the session, etc. 3. xsupplicant: # iwconfig eth0 essid "blabla" key 0x0 (apparently some cards will require 0x0, while others will require something different than 0x0, try e.g. 0x1234567890 then. without it xsupplicant won't associate to APs enforcing encryption.) # ifconfig eth0 allmulti up then, with your configuration # xsupplicant -i eth0 should work. I'm a little reluctant to use HostAP, since it will increase the HOWTO and the complexity even more... WPA and 802.11i support is beeing worked on for Xsupplicant.. anyway, HostAP is for PRISM cards only - imho, there are no more PRISM cards on the market (even if i believe that some other chipset will be rev-inged once) Why? To let the interface recive new session/broadcast keys? apparently, there are issues with some card drivers: xsupplicant won't work without it. for details, see xsupplicant list archives. as far as i know, allmulti does not hurt, so you can always add it. ciao artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Is Release 1.0.0 available?
hi No. I was going to release it last Friday, but my wife released "Baby 1.0" first. That took priority, oddly enough. Give me a few days to sleep... Alan DeKok. wow, really??? i can only hope then that this time the feature freeze came early enough and that the involved developers did a good job and gave their best: i hope that the patches won't be necessary :-) congratulations and my sincere best wishes! ciao artur ps list owner: couldn't we forbid Alan any postings/readings for two weeks or so? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 802.1X HOWTO (draft)
ah, nice. i took a rapid look, it looks good. just some detials: 1. the document needs a quick native speaker review. guys? 2. remove the repetitions of the form "how 802.1X works". 3. add links to XSupplicant and FreeRadius in the abstract. 4. Authenticator config: since the images you include are HTML pages, you can reduce the overall document size using the trick used in e.g.: http://www.freeradius.org/doc/EAP-MD5.html (not important) also add an image on EAP usage configuration (you only have the radius related config, where is the SSID-related config?) 5. WPA / RSN: stop confusing people even more :-) try this: TSN = TKIP+WPA/RADIUS = WPA(1) RSN = CCMP+WPA/RADIUS = WPA2 basically, if you really want to explain stuff instead of just saying "do that, do this" you can add an explanation divided in several sections which are to consider: - network access control (here: always 802.1X) - authentication method (with 802.1X EAP is implied) - link layer encryption (TKIP, CCMP, WEP, etc.) - backend server (EAP-capable RADIUS server implied by 802.1X) - magic glue :-) i.e. all the conventions on how and when to derive what and from what and how often and how to transport all this between AS/A etc., 6. in the Xsupplicant section: Configuring Xsupplicant, point 5: are you sure that "/sbin/iwconfig eth0 mode managed essid testnet enc off" will let you associate with networks mandating WEP or TKIP usage? have you tried that with an access point which requires L2 encryption? my card would not associate to WEP-networks unless i do "iwconfig eth= key 0x0" or provide some bogus key. also, why not adding "allmulti" to the "ifconfig eth0 up" directive? otherwise it looks good to me artur Lars Strand wrote: I'm in the process of writing an 802.1X Linux HOWTO using Xsupplicant as supplicant and FreeRADIUS as authentication server. The authentication mechanism used is PEAP (MS-CHAPv2). You may find the draft here: http://www.gnist.org/~lars/courses/04thales/8021X-HOWTO.html I would like some comments/hints/tips! And, when you guys are satisfied, I plan to submit it to tldp.org. Thanks! - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Gmail
this feature is usually called "reading emails in threads" and it probably exists since the creation of email in _every_ client i know. i recommend you stop advertising for gmail here. ciao artur Evan Stenmark wrote: If you use email to search through the freeradius-users list, then I recommend gmail because of the way it handles "conversations." It is similar to a forum. A conversation is the first message and all the replies to that message. It puts all the conversations together so you don't have to search through a long list of messages like what would be done in a normal inbox. Naturally, you can get this same effect by going through the mail archive www.mail-archive.com/freeradius-users%40lists.freeradius.org/ Gmail is still in the beta phase and you must get an invite (or buy one from ebay) to get a gmail account. Evan Stenmark - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Aironet 1200 / TLS-PEAP / FreeRADIUS
hi sorry, it was my fault, i misread your "XP supplicant" as xsupplicant. :-) some kind if issue between the Cisco card and xsupplicant? I have yes, indeed there is. xsupplicant does not seem to support the way the newest drivers handle some packets. Pardon my RADIUS newbie wording... "all aspects of authentication" is a bit exclusive, isn't it? What I meant to say, is that I don't understand why a wireless device can't just work at the lowest common denominator, and let the supplicant and the authenticator do all of the communication. I understand that there are driver/firmware issues with cards, but why does it have to be this way? Isn't there just an exchange of EAP info? there is. however, EAP is not data, it is encapsulated in EAPOL which is a protocol using a special ethernet frame type. the card's firmware should explicitly know this new ethernet frame type since otherwise it would just drop it, right from the hardware. now, once you've changed the firmware of the card, the supplied driver has to provide the necessary API for windows to access to these packets and write them, etc. since at the beginning there were multiple different drafts of the 802.1X document, some things have changed and are a bit different today. depending on your card and your AP there can be issues... hey, what's so surprising? don't you remember the times as Cisco wireless cards could not connect to Lucent Access points though both were sold as 802.11 compliant? that's when the WiFi test was born... greetings artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alan, can you take a look -> Re: Problem regarding WinXP+Freeradius+EAP-TLS packet sequence
hi Anyway I have tested even without any User-Password entry against XP's "Administrator" login. And surprisingly got same result (that "Success" message before client certificate verification). Am I doing someting wrong? well, imho, it should not behave in a wrong way even if there is a user... i wanted to ask you which supplicant you are using or generally how you managed not to send the client certificate (if this is really the case) since the most supplicants would do so automatically. ok, so the interesting part of the log starts here: rlm_eap_tls: Length Included eaptls_verify returned 11 (other): before/accept initialization TLS_accept: before/accept initialization rlm_eap_tls: <<< TLS 1.0 Handshake [length 0041], ClientHello TLS_accept: SSLv3 read client hello A rlm_eap_tls: >>> TLS 1.0 Handshake [length 004a], ServerHello TLS_accept: SSLv3 write server hello A rlm_eap_tls: >>> TLS 1.0 Handshake [length 0694], Certificate TLS_accept: SSLv3 write certificate A rlm_eap_tls: >>> TLS 1.0 Handshake [length 00b1], CertificateRequest TLS_accept: SSLv3 write certificate request A TLS_accept: SSLv3 flush data TLS_accept:error in SSLv3 read client certificate A In SSL Handshake Phase In SSL Accept mode eaptls_process returned 13 ok, if i understand it correctly, it could not read the client certificate (which is quite normal here because it is just requesting the certificate). so in the next message the requested certificate should appear. but: i could be VERY wrong in these wild assumptions. what you can do, is to compare this log to the log of Ken Roser out of his PDF-howto (it's on the freeradius website). modcall[authenticate]: module "eap" returns handled for request 1 modcall: group authenticate returns handled for request 1 Sending Access-Challenge of id 4 to 10.0.0.1:21645 EAP-Message = 0x0104040a0dc0079e160301004a0246030140c5b760373179a906f712e477ff2addbba152897af7bb796e864f74fa5e447b20a773c1f550b1bef0d013e9c9e35e5ab375bb1f1524a27d276199b2342fccd7bc00040016030106940b0006968d0002cd308202c930820232a003020102020102300d06092a864886f70d010104050030819f310b30090603550406130243413111300f0603550408130850726f76696e63653112301006035504071309536f6d65204369747931153013060355040a130c4f7267616e697a6174696f6e31123010060355040b13096c6f63616c686f7374311b301906035504031312436c69656e74206365 EAP-Message = 0x7274696669636174653121301f06092a864886f70d0109011612636c69656e74406578616d706c652e636f6d301e170d3034303132353133323631305a170d3035303132343133323631305a30819b310b30090603550406130243413111300f0603550408130850726f76696e63653112301006035504071309536f6d65204369747931153013060355040a130c4f7267616e697a6174696f6e31123010060355040b13096c6f63616c686f73743119301706035504031310526f6f74206365727469666963617465311f301d06092a864886f70d0109011610726f6f74406578616d706c652e636f6d30819f300d06092a864886f70d010101050003 EAP-Message = 0x818d0030818902818100dac525422bfedb082629a2cba44b3449c90d0ab462fb72c8434a782098863d7eb7d7e70028c2b7ad555a51cc756cf4fa1d7091615ab450d5289553ae6616aff014a55085d6b8fb4aee98638e426175cdd36c665c63cda177d34920eb30585edc8773999c2980f81ad4638bbbea1c82d054023db7ef24a3ec1c3f6241a903d7f30203010001a317301530130603551d25040c300a06082b06010505070301300d06092a864886f70d0101040500038181007a2d921b1cf13bf2982a9178ec9ede6d88edc178a2e8bd40a0a06fb6f0769957884cd7084537083496fd184165293f583c8e8240eb68e042c94b15752e4c07e80d09 EAP-Message = 0x779afa3dd55c24fa54ac292d77205d1c2477ed30d59f57caf9bd21ff2a8d16cc0911c50e4f295763fcb60efa3c3d2d0e43850f6e6fbe284902f6e83503650003ba308203b63082031fa003020102020100300d06092a864886f70d010104050030819f310b30090603550406130243413111300f0603550408130850726f76696e63653112301006035504071309536f6d65204369747931153013060355040a130c4f7267616e697a6174696f6e31123010060355040b13096c6f63616c686f7374311b301906035504031312436c69656e742063657274696669636174653121301f06092a864886f70d0109011612636c69656e74406578616d706c EAP-Message = 0x652e636f6d301e170d3034303132353133323630375a Message-Authenticator = 0x State = 0x2852b1a60ade88586b0a538bdc340943 ok, so it's sent the request. Finished request 1 Going to the next request Waking up in 6 seconds... rad_recv: Access-Request packet from host 10.0.0.1:21645, id=5, length=150 User-Name = "Administrator" Framed-MTU = 1400 Called-Station-Id = "000f.24a0.9ee0" Calling-Station-Id = "0004.e280.fb7b" Message-Authenticator = 0x6a14a6b264e5a205e622d32e29904386 EAP-Message = 0x020400060d00 NAS-Port-Type = Wireless-802.11 NAS-Port = 260 State = 0x2852b1a60ade88586b0a538bdc340943 Service-Type = Framed-User NAS-IP-Address = 10.0.0.1 NAS-Identifier = "IXIA-AP" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 2 modcall[authorize]: module "preprocess" returns ok for request
Re: Aironet 1200 / TLS-PEAP / FreeRADIUS
hi Epp, Ladd J wrote: Turns out that the wireless adapter I was using wasn't working right with EAP. I'm not sure why. I finally got a hold of a Cisco 350 PCMCIA card and it worked almost immediately using the XP supplicant. well, that's surprising: my cisco 350 would not do dynamic WEP with xsupplicant. it does the authentication but not the new key setting. how did you get to do that? do you use dynamic WEP? It's kind of frustrating to realize that some wireless adapters work with 802.1x, and others don't. It seems logical to me that the well, that can be e.g. a firmware issue of the card. supplicant would control all aspects of authentication. Obviously this isn't the case. supplicant??? you mean authenticator, don't you? well, the authenticator does control a lot but if the supplicant is not responding correctly, it does not care. the authenticator is like a bouncer at the disco entry: he wouldn't let you in if you do not know the boss but he does nothing if you are not even trying to come in. ciao artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem regarding WinXP+Freeradius+EAP-TLSpacket sequence
hi freeradius NEVER sends the EAPOL Key message. also the sending of an encapsulated EAP-Success is without any interest. The AP only wants to see the Access-Accept and that is what freeradius is responsible for. Yes that's true. EAPOL Key messages are sent by AP. But as freeradius is sending Access-Accept in this case so AP is sending EAP-Success message. But the strange thing is why it is sending Access-Accept message without checking client certificate. read above what i've said: the included eap-success message is not evaluated by the AP, only the Access-Accept counts. even if an EAP-Failure is included within the Access-Accept, the AP should issue an EAP-Success, s. 802.1X standard. and of course that has nothing to do with the discussion :-) why did you set the User-Password? you do not need any user password. just comment out both lines and try again. I am very new in freeradius. I am not sure here what should I use/set as Auth-Type. Can you please suggest me? Also I will check EAP-TLS without User-Password entry against "Administrator" login by tommorrow. nothing. do not configure ANY user. typically, if a user profile is present, it should contain further restrictions (Session-Timeout, etc.). if you do not have any, do not configure the user. ciao artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alan, to your atttention - Re: Problem regarding WinXP+Freeradius+EAP-TLS packet sequence
hi alan, please see the remark in text. [EMAIL PROTECTED] wrote: I am testing EAP-TLS with Windows XP(EAP-TLS supplicant) , Freeradius(running on Redhat 9) and Cisco Aironet 1100 series Access Point. I have done all the required setup and EAP-TLS authentication has been successful with that setup. But the problem is within the EAP-TLS packet sequence. From the ethereal capture (from WinXP) it is shown that after "Server hello/Certificate/Certificate Request/Server hello done" packet transmission freeradius is sending "EAP-Success" message followed by "EAPOL-Key" messages (rsdius log also displays freeradius NEVER sends the EAPOL Key message. also the sending of an encapsulated EAP-Success is without any interest. The AP only wants to see the Access-Accept and that is what freeradius is responsible for. the same sequence). There is no evidence of transmitting "Client certificate/Client Key exchange" message from XP supplicant. But according to the RFC Client MUST provide certificate whenever server requests for a client certificate. So in turn there does not occur any client side authentication, only server side authentication has been done. I am testing against XP's "Administrator" login. why did you set the User-Password? you do not need any user password. just comment out both lines and try again. (also why did you explicitly set the Auth-Type? the eap.conf *shouts* that you should not do that.) I am not sure whether it's a right behaviour from XP/Freeradus or I have to change setup to make the thing working correctly. So please can anyone help on this matter? actually, IMHO, it's not. even provided with a user-password the TLS module should not just accept the user. alan, what do you think, is it a bug? even if i configure a user with a user-password, the TLS module should not just accept him without Client Certificate request, should it? ciao artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Aironet 1200 / TLS-PEAP / FreeRADIUS
hi WDS allows clients to roam between access points without having to re-associate each time. It communicates with the RADIUS server for authentication between access points. I have been successful in getting that to authenticate. ok, looks like a proprietary IAPP to me. IAPP uses TCP from client to client, as far as i know. if WDS related Radius traffic arrives at the Radius server, then nothing blocks. then you probably just forgot to activate this special server as EAP server OR you do not have any SSID which includes EAP treatment (the AP has nothing to send). you have to define at least one SSID as OPEN - with EAP. It's odd how simple the EAP configuration should be (or is)... it makes me wonder if there is something wrong with my AP. today, it _is_ simple ciao artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Aironet 1200 / TLS-PEAP / FreeRADIUS
hi If I set up my access point as a Wireless Domain Service, it can communicate with the FreeRADIUS server, no problem. So, there aren't any communication blocks going on here. The odd things is that I've followed well, i don't know what WDS is (if you have any futher info on this, i'm always glad to learn). it could be in TCP though and thus go through NAT while radius traffic would not. many different how-to's on Cisco/EAP, but still no luck. Anyway, I know this is out of scope but if someone has worked with this configuration and could help me out it would be most appreciated. actually, there is hardly anothing to configure. - you put a radius server with a shared secret into your Cisco AP - you say that this server is used for EAP auth - you say that your SSID your_ssid is using Open Auth with EAP. - you add the current cisco IP to the freeradius' clients file, along with the same shared secret - you are the man who has all working. probably you also want to activate link encryption and to use dynamic WEP keys etc. but strictly spoken this has little to do with the first and most important phase. ciao artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Aironet 1200 / TLS-PEAP / FreeRADIUS
hi Has anyone here had any experience with the Aironet 1200 / TLS-PEAP / FreeRADIUS combination of hardware/software? For some reason, the yes. it works. Aironet is not trying to communicate with FreeRADIUS (radiusd –XX shows no communication attempts). I know this is leaning more towards a Cisco either your cisco is misconfigured or there is no communication between the both possible: something could be blocking requests (firewall, NAT, etc.) problem, but I’ve tried posting to several lists and no one seems to know (or cares to respond). If anyone could help me out it would be greatly appreciated. Below is the debug output from the Cisco AP, and below that is the AP configuration. I would post the FreeRADIUS debug stuff, but there is none (no communication attempts). if there is not even any "request from bad client", then it has nothing to do with freeradius, as you've already said. freeradius will work and do what you want it do without anything special to be configured in it. just define a user (only User-Password) and a NAS. that's all for freeradius. the rest is out of scope, sorry. ciao artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP/TLS win2000
hi Unless you tell it to use some other identity (there is a check box you can mark) I've tryed that, but nothing happened. sorry, i actually didn't mean to tell that windows would send messages in that case. actually, i don't know if it will send anything, it still needs the certificate for TLS. one silly question: did you activate the Wireless Zero Config service under Win2k? (it's called "Configuration something" in french). because if it's not the case, it's not gonna work. I think client and root cert are valids, then I'm going to contrôl the place where they have to be yes try that. the certificates also need the corresponding extensions, don't forget. ciao artr -- Artur Hecker artur[at]hecker.info - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Help to a student on final exam paper
hi jacob I have installed Cistron Radius 1.6.6 on my redhat 9.0 machine. My goal is to authenticate all users on a wireless 802.1x network, and here are the specs. huh... i'm not sure cistron radius does 802.1X; perhaps you should take freeradius, the latest pre-release... Router: 10.10.0.1 Gateway(Clark Connect)/ Cistron radius server: ExternalEth0 10.10.0.101 DHCP Lan Eth1192.168.1.1 Static Accecpoint ( Zyxel Zyair - Not transparent) Wan: 192.168.1.2 Lan: 192.168.2.1 what exactly do you mean by not transparent??? Users on the LAN side of the accespoint is given a static IP adress, and my soul aim is to authenticate these users when they log on to the internet. I have installed the radius server, almost succesfull, but no prompt appears when logging on to the internet ?? The clients simply log on to the internet, without being promted for a user/pass. Here are som tests, configs from the radius server: the enforcement of the access control should be done within the access point. i.e. if the users are granted access, you did not configure your access point. i suggest you take an hour or two to understand how 802.1X works. this can be done by reading some documents on the web. then, you'll see that everything will work just fine given that your access point supports 802.1X. Sumsar Password="Beatles", Simultaneous-Use =1, Expiration_"Jan 01 2020" Service-Type = Framed-User, Framed-Protocol = PPP, Framed-IP-Address = 255.255.255.254, Framed-Routing = None DEFAULT Auth-Type = System Fall-Through = 1 all this won't be necessary for 802.1X users. ciao artur -- Artur Hecker artur[at]enst[d]fr - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP/TLS win2000
hi Frederic I think, they are well installed, like it's explained in most HOWTOs, but.. then i don't know. What do you want to say is that win2K is going to take EAP-Identity value in client certificate, before EAP-TLS challenge start ?? I don't think so, it doesn't work like that with Xsupplicant/FreeRADIUS and it's not describe like this in RFC. no. what i want to say is that you force Windows to use EAP/TLS and it gets now the EAP Request Identity message. it has to reply to this message and it does need at least one identity for that. Unless you tell it to use some other identity (there is a check box you can mark), it will automatically take the CN out of the installed certificate. If there is no certificate (or it is not where it should be, or it is in the machine repository but the machine identification is not on, or the certificate is invalidated by something like expiration or not available root certificate or or or or), well then Windows simply does not have any idea what to reply to the Authenticator, does it? ciao artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP/TLS win2000
hi Thx for your help Artur, but I forgot to say my authenticator is a Cisco switch 3550, then not a wireless access-point. There's something I don't understand, with PEAP or EAP-MD5, the windows 2000 supplicant answer to identity request send by the switch but with EAP-TLS, it stay sleeping without doing anything... Maybe someone can confirm me that there's no bug beetween windows 2000 and EAP-TLS. Thx again. that would be quite strange, except of course you did not have the client certificates installed at the right place etc. verify that they are in the right repository. windows can't ask you anything if you don't have any user certificate. ciao artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FreeRADIUS + MySQL +EAP-TLS
yes, who are neither in users nor in the SQL db. ciao artur ro0ot wrote: So, it will reject users that is not in the /etc/raddb/users file? Regards, ro0ot NGUYEN Tuan Anh wrote: It works!! Thank you very much Artur!! Ciao Artur Hecker wrote: hi ok, that's a bit messy though. take a look at the mysql config and the queries mentioned in the sql.conf file. see also the default profile. play with it and its options and add an Auth-Type := Reject to the default profile. thus, every unknown user will be added an Auth-Type := Reject line and will be rejected without any EAP module interacting. the only problem you will be left is are certified users who will still can connect as some other certified users. ciao artur NGUYEN Tuan Anh wrote: What do you mean "explicitly REJECT"? How can I do it? Thanks a lot! Ciao Tuan anh Artur Hecker wrote: yes, that's normal since the authentication works for ALL validly certified clients. you have to explicitly REJECT the users NOT in your data base. ciao artur NGUYEN Tuan Anh wrote: Hi, I'm trying to install a system with FreeRADIUS and MySQL and EAP-TLS as authentication protocol. Everything works, but I have a problem (I think it's a problem of configuration) : If I have a client with a valid certificate, even though the sql module doesn't regcognize the client (user-name doesn't existe in check list, the eap module always accept that client so the authorize section always return Acess-Accept!! Here 's part of the debug : rad_recv: Access-Request packet from host 134.214.78.43:6001, id=134, length=1256 User-Name = "LEPILLEUR Benjamin" NAS-IP-Address = 134.214.78.43 Called-Station-Id = "00-08-02-76-8d-32" Calling-Station-Id = "00-04-23-71-13-4c" NAS-Identifier = "PTSGSF3" State = 0xc89112eb62ee9f6f95ca9d43f018c9378ff6b54098811a92e7909de796d82c6ebc2dc2c1 Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x0205043d0d80043316030104030b0002f30002f2ed308202e930820252a00302010202020805300d06092a864886f70d01010505003045310b300906035504061302465231153013060355040a130c54454c45434f4d2d4c444150311f301d060355040313164944582d504b49204f7065726174696f6e616c204341301e170d3034303332323135343634345a170d3035303332323135343634345a3051310b3009060355040613024652310d300b060355040a1304494e534131163014060355040b130d54656c65636f6d202d20475346311b3019060355040313124c4550494c4c422042656e6a616d696e30819f300d06092a8648 EAP-Message = 0x86f70d010101050003818d0030818902818100b951865a184af898f572fe6c23e93fc536026799577ba60d5b81de327bc451a7ff1d6caac19770ff8a02e0f407263edd970ddd4e15249f664c1cbd1283fd24dead1267fb166db68dc2de9f1cf9af8c9c9d10029d73156bec314ca8e24687401757ac92da50e1fc43d042e509a63b528d24e48891251026e21a1a8a6a911be6eb0203010001a381db3081d8301d0603551d0e041604140a3e625d09037edccffca0b769f7036177330814301f0603551d230418301680146b8d4761901ff704c5d8b7dc07051d49447e30e930280603551d1f0421301f301da01ba0198617687474703a2f2f74632d706b EAP-Message = 0x692f4f7043524c2e63726c302a0603551d1104233021811f62656e6a616d696e2e6c6570696c6c65757240696e73612d6c796f6e2e6672300e0603551d0f0101ff0404030205a0301d0603551d250416301406082b0601050507030406082b06010505070302301106096086480186f84201010404030205a0300d06092a864886f70d010105050003818100a891927dc519f6f67fec7ffa5d18d58a2715145d9107903b109bfc8b35bc9e554796f83daf95d20bdf00a5e914a84f34d1eeda29a9d7d5541db2b6e67d65479d892bc98a9ae342a6b17b54bf1f2218913dbbfeb6cc93514e02d703afa762df2d43ede10b2e23631b94673374fd8acf338a EAP-Message = 0xde8fb4f97b3bb969e68e4ab80c73bc10820080111d7cb9d30649cac83e726c7c0d3f2513824e554db91feb1cc0c6d9188c625dab13d21750a259d6e53f6375f1687e529d55ae80079b007e163bcff10a6eaac9832d3ec16341eecc335044436e40d9ae4c5011cb6b3fd6730283be164eb76e9c71d5776947acaebda2efef9f5f5712fb222bef84f2fa392505ab50523c04f40b0f820080904cb7af1212010b2d9377082c19aed35a83cdc9cc4a0f8d630c88d7996a86ec897f499caa6cb077b2d31d717211544d9c5e8e813c8b152d2d23f1de6b390873d62b33d2088eb3161acc5ed71c2d7df759c99d231f4af4e92671b30fbd545ebdde10 EAP-Message = 0x8121e1559fea1e3bffa3f781d173bc9147524762908effca4d1e6cb7d83914030100010116030100202e9086427690428d6a55f8e7e92f92a81884b32d074bb23725aca664aedbde6e Message-Authenticator = 0xbd5a866d0c2167835c811f8122ff9ada modcall: entering group authorize for request 3 radius_xlat: 'LEPILLEUR Benjamin' rlm_sql (sql): sql_set_user escaped user --> 'LEPILLEUR Benjamin' radius_xlat: 'SELECT id,UserName,Attribute,UserName,op FROM radcheck WHERE Username = 'LEPILLEUR Benjamin' ORDER BY id' rlm_sql (sql): Reserving sql socket id: 1 rlm_sql_mysql: query: SELECT id,UserName,Attribute,UserName,op FROM radcheck WHERE Username = 'LEPILLEUR Benjamin' ORDER BY id rlm_sql (sql): User LEPILLEUR Benjamin not found in radcheck radius_xlat: '' radius_xla
Re: FreeRADIUS + MySQL +EAP-TLS
hi ok, that's a bit messy though. take a look at the mysql config and the queries mentioned in the sql.conf file. see also the default profile. play with it and its options and add an Auth-Type := Reject to the default profile. thus, every unknown user will be added an Auth-Type := Reject line and will be rejected without any EAP module interacting. the only problem you will be left is are certified users who will still can connect as some other certified users. ciao artur NGUYEN Tuan Anh wrote: What do you mean "explicitly REJECT"? How can I do it? Thanks a lot! Ciao Tuan anh Artur Hecker wrote: yes, that's normal since the authentication works for ALL validly certified clients. you have to explicitly REJECT the users NOT in your data base. ciao artur NGUYEN Tuan Anh wrote: Hi, I'm trying to install a system with FreeRADIUS and MySQL and EAP-TLS as authentication protocol. Everything works, but I have a problem (I think it's a problem of configuration) : If I have a client with a valid certificate, even though the sql module doesn't regcognize the client (user-name doesn't existe in check list, the eap module always accept that client so the authorize section always return Acess-Accept!! Here 's part of the debug : rad_recv: Access-Request packet from host 134.214.78.43:6001, id=134, length=1256 User-Name = "LEPILLEUR Benjamin" NAS-IP-Address = 134.214.78.43 Called-Station-Id = "00-08-02-76-8d-32" Calling-Station-Id = "00-04-23-71-13-4c" NAS-Identifier = "PTSGSF3" State = 0xc89112eb62ee9f6f95ca9d43f018c9378ff6b54098811a92e7909de796d82c6ebc2dc2c1 Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x0205043d0d80043316030104030b0002f30002f2ed308202e930820252a00302010202020805300d06092a864886f70d01010505003045310b300906035504061302465231153013060355040a130c54454c45434f4d2d4c444150311f301d060355040313164944582d504b49204f7065726174696f6e616c204341301e170d3034303332323135343634345a170d3035303332323135343634345a3051310b3009060355040613024652310d300b060355040a1304494e534131163014060355040b130d54656c65636f6d202d20475346311b3019060355040313124c4550494c4c422042656e6a616d696e30819f300d06092a8648 EAP-Message = 0x86f70d010101050003818d0030818902818100b951865a184af898f572fe6c23e93fc536026799577ba60d5b81de327bc451a7ff1d6caac19770ff8a02e0f407263edd970ddd4e15249f664c1cbd1283fd24dead1267fb166db68dc2de9f1cf9af8c9c9d10029d73156bec314ca8e24687401757ac92da50e1fc43d042e509a63b528d24e48891251026e21a1a8a6a911be6eb0203010001a381db3081d8301d0603551d0e041604140a3e625d09037edccffca0b769f7036177330814301f0603551d230418301680146b8d4761901ff704c5d8b7dc07051d49447e30e930280603551d1f0421301f301da01ba0198617687474703a2f2f74632d706b EAP-Message = 0x692f4f7043524c2e63726c302a0603551d1104233021811f62656e6a616d696e2e6c6570696c6c65757240696e73612d6c796f6e2e6672300e0603551d0f0101ff0404030205a0301d0603551d250416301406082b0601050507030406082b06010505070302301106096086480186f84201010404030205a0300d06092a864886f70d010105050003818100a891927dc519f6f67fec7ffa5d18d58a2715145d9107903b109bfc8b35bc9e554796f83daf95d20bdf00a5e914a84f34d1eeda29a9d7d5541db2b6e67d65479d892bc98a9ae342a6b17b54bf1f2218913dbbfeb6cc93514e02d703afa762df2d43ede10b2e23631b94673374fd8acf338a EAP-Message = 0xde8fb4f97b3bb969e68e4ab80c73bc10820080111d7cb9d30649cac83e726c7c0d3f2513824e554db91feb1cc0c6d9188c625dab13d21750a259d6e53f6375f1687e529d55ae80079b007e163bcff10a6eaac9832d3ec16341eecc335044436e40d9ae4c5011cb6b3fd6730283be164eb76e9c71d5776947acaebda2efef9f5f5712fb222bef84f2fa392505ab50523c04f40b0f820080904cb7af1212010b2d9377082c19aed35a83cdc9cc4a0f8d630c88d7996a86ec897f499caa6cb077b2d31d717211544d9c5e8e813c8b152d2d23f1de6b390873d62b33d2088eb3161acc5ed71c2d7df759c99d231f4af4e92671b30fbd545ebdde10 EAP-Message = 0x8121e1559fea1e3bffa3f781d173bc9147524762908effca4d1e6cb7d83914030100010116030100202e9086427690428d6a55f8e7e92f92a81884b32d074bb23725aca664aedbde6e Message-Authenticator = 0xbd5a866d0c2167835c811f8122ff9ada modcall: entering group authorize for request 3 radius_xlat: 'LEPILLEUR Benjamin' rlm_sql (sql): sql_set_user escaped user --> 'LEPILLEUR Benjamin' radius_xlat: 'SELECT id,UserName,Attribute,UserName,op FROM radcheck WHERE Username = 'LEPILLEUR Benjamin' ORDER BY id' rlm_sql (sql): Reserving sql socket id: 1 rlm_sql_mysql: query: SELECT id,UserName,Attribute,UserName,op FROM radcheck WHERE Username = 'LEPILLEUR Benjamin' ORDER BY id rlm_sql (sql): User LEPILLEUR Benjamin not found in radcheck radius_xlat: '' radius_xlat: '' rlm_sql (sql): Released sql socket id: 1 modcall[authorize]: module "sql" returns ok for request 3 radius_xlat: '/usr/local/var/log/radius/radacct//auth-detail-20040527' rlm_detail: /usr/local/var/log/radius
Re: Access Reject
congratulations, your server works as it should. Access Reject is NOT an error, it's what the server is supposed to do for the unknown users. ciao artur ps [EMAIL PROTECTED]:~$ radtest --help Usage: radtest user passwd radius-server[:port] nas-port-number secret i don't think you have a user named localhost with passwd testing123. Mahesh S Kudva wrote: Hi all I am trying the freeradius server version 0.9.3. Everything from compiling to installation went fine. When I give radtest localhost testing123 127.0.0.1 10 testing123 it give a Access reject error. Regards & Thanks Mahesh S Kudva - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FreeRADIUS + MySQL +EAP-TLS
yes, that's normal since the authentication works for ALL validly
certified clients.
you have to explicitly REJECT the users NOT in your data base.
ciao
artur
NGUYEN Tuan Anh wrote:
Hi, I'm trying to install a system with FreeRADIUS and MySQL and EAP-TLS
as authentication protocol. Everything works, but I have a problem (I
think it's a problem of configuration) : If I have a client with a valid
certificate, even though the sql module doesn't regcognize the client
(user-name doesn't existe in check list, the eap module always accept
that client so the authorize section always return Acess-Accept!! Here
's part of the debug :
rad_recv: Access-Request packet from host 134.214.78.43:6001, id=134,
length=1256
User-Name = "LEPILLEUR Benjamin"
NAS-IP-Address = 134.214.78.43
Called-Station-Id = "00-08-02-76-8d-32"
Calling-Station-Id = "00-04-23-71-13-4c"
NAS-Identifier = "PTSGSF3"
State =
0xc89112eb62ee9f6f95ca9d43f018c9378ff6b54098811a92e7909de796d82c6ebc2dc2c1
Framed-MTU = 1400
NAS-Port-Type = Wireless-802.11
EAP-Message =
0x0205043d0d80043316030104030b0002f30002f2ed308202e930820252a00302010202020805300d06092a864886f70d01010505003045310b300906035504061302465231153013060355040a130c54454c45434f4d2d4c444150311f301d060355040313164944582d504b49204f7065726174696f6e616c204341301e170d3034303332323135343634345a170d3035303332323135343634345a3051310b3009060355040613024652310d300b060355040a1304494e534131163014060355040b130d54656c65636f6d202d20475346311b3019060355040313124c4550494c4c422042656e6a616d696e30819f300d06092a8648
EAP-Message =
0x86f70d010101050003818d0030818902818100b951865a184af898f572fe6c23e93fc536026799577ba60d5b81de327bc451a7ff1d6caac19770ff8a02e0f407263edd970ddd4e15249f664c1cbd1283fd24dead1267fb166db68dc2de9f1cf9af8c9c9d10029d73156bec314ca8e24687401757ac92da50e1fc43d042e509a63b528d24e48891251026e21a1a8a6a911be6eb0203010001a381db3081d8301d0603551d0e041604140a3e625d09037edccffca0b769f7036177330814301f0603551d230418301680146b8d4761901ff704c5d8b7dc07051d49447e30e930280603551d1f0421301f301da01ba0198617687474703a2f2f74632d706b
EAP-Message =
0x692f4f7043524c2e63726c302a0603551d1104233021811f62656e6a616d696e2e6c6570696c6c65757240696e73612d6c796f6e2e6672300e0603551d0f0101ff0404030205a0301d0603551d250416301406082b0601050507030406082b06010505070302301106096086480186f84201010404030205a0300d06092a864886f70d010105050003818100a891927dc519f6f67fec7ffa5d18d58a2715145d9107903b109bfc8b35bc9e554796f83daf95d20bdf00a5e914a84f34d1eeda29a9d7d5541db2b6e67d65479d892bc98a9ae342a6b17b54bf1f2218913dbbfeb6cc93514e02d703afa762df2d43ede10b2e23631b94673374fd8acf338a
EAP-Message =
0xde8fb4f97b3bb969e68e4ab80c73bc10820080111d7cb9d30649cac83e726c7c0d3f2513824e554db91feb1cc0c6d9188c625dab13d21750a259d6e53f6375f1687e529d55ae80079b007e163bcff10a6eaac9832d3ec16341eecc335044436e40d9ae4c5011cb6b3fd6730283be164eb76e9c71d5776947acaebda2efef9f5f5712fb222bef84f2fa392505ab50523c04f40b0f820080904cb7af1212010b2d9377082c19aed35a83cdc9cc4a0f8d630c88d7996a86ec897f499caa6cb077b2d31d717211544d9c5e8e813c8b152d2d23f1de6b390873d62b33d2088eb3161acc5ed71c2d7df759c99d231f4af4e92671b30fbd545ebdde10
EAP-Message =
0x8121e1559fea1e3bffa3f781d173bc9147524762908effca4d1e6cb7d83914030100010116030100202e9086427690428d6a55f8e7e92f92a81884b32d074bb23725aca664aedbde6e
Message-Authenticator = 0xbd5a866d0c2167835c811f8122ff9ada
modcall: entering group authorize for request 3
radius_xlat: 'LEPILLEUR Benjamin'
rlm_sql (sql): sql_set_user escaped user --> 'LEPILLEUR Benjamin'
radius_xlat: 'SELECT id,UserName,Attribute,UserName,op FROM radcheck
WHERE Username = 'LEPILLEUR Benjamin' ORDER BY id'
rlm_sql (sql): Reserving sql socket id: 1
rlm_sql_mysql: query: SELECT id,UserName,Attribute,UserName,op FROM
radcheck WHERE Username = 'LEPILLEUR Benjamin' ORDER BY id
rlm_sql (sql): User LEPILLEUR Benjamin not found in radcheck
radius_xlat: ''
radius_xlat: ''
rlm_sql (sql): Released sql socket id: 1
modcall[authorize]: module "sql" returns ok for request 3
radius_xlat: '/usr/local/var/log/radius/radacct//auth-detail-20040527'
rlm_detail:
/usr/local/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d
expands to /usr/local/var/log/radius/radacct//auth-detail-20040527
modcall[authorize]: module "auth_log" returns ok for request 3
rlm_eap: EAP packet type notification id 5 length 1085
rlm_eap: EAP Start not found
modcall[authorize]: module "eap" returns updated for request 3
modcall: group authorize returns updated for request 3
rad_check_password: Found Auth-Type EAP
auth: type "EAP"
modcall: entering group authenticate for request 3
rlm_eap: EAP packet type notification id 5 length 1085
rlm_eap: EAP Start not found
rlm_eap: Request found, released from the list
rlm_eap: EAP_TYPE - tls
rlm_eap: processing type tls
rlm_eap_tls: Authenticate
rlm_eap_tls: Length Included
rlm_eap_tls: <<< TLS 1.0 Handshake [length 02f7], Cer
Re: EAP/TLS win2000
i think the problem is that you are trying to use WEP within your access point but no WEP is configured within the 802.11 client on the terminal (which is NOT included in Win2k). use the external 802.11 client of your wireless network adapter and activate WEP (whichever form of it). that will permit the WinéK built-in 802.1X client to communicate. ciao artur Frédéric EVRARD wrote: Hi all, I'm using 802.1x/EAP-TLS on FreeRADIUS, it works fine with linux Xsupplicant but not with Win2000 supplicant, when supplicant receives EAP request Identity packet, it doesn't answer anything and nothing happens...There's no logs or I don't know to find them. I've read several HOWTO but nothing help me.If someone has the solution. THX. Fred - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: [Q]: Assigning VLANs and restricting logins?
hi strictly spoken, the server-to-client communication is not defined within RADIUS protocol which follows the client-server comm. model. this possibility does exist in DIAMETER (if you find an NAS which understands it, please shout!) practically, cisco does something like that in RADIUS (but it's of course proprietary to the cisco equipment) and you can disconnect by using scripts etc., i.e. basically by leaving the radius context. ciao artur Damjan wrote: Admin can/would log off the logged in clients on the domain that the RADIUS server resides. That's not a problem. But how does one tell NAS equipment about it? In my case, What would be the protocol to do ask NAS equipment to disassociate certain clients? Obviously that depends from NAS to NAS, for ex. I can telnet into my dial-up access server and kick a user by his ID. btw, if you don't tell the NAS equipment that a user should be logged-off you've done nothing by "Admin can/would log off the logged in clients on the domain that the RADIUS server resides". What would that accomplish (I dont even understand how do you think that will work?!?) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Dynamic VLAN assignment
:-) ok, though i don't know what these magic private VLANs would be technically... with VLANs either you mark ports or you mark packets. what can they do in an AP? they can mark the port where it's plugged in as VLANx or they can make the AP send packets marked as appertaining to VLANx... well... i guess you have enough VLAN-ids for a while but installing them in the switches is kind of dumb work ciao artur Dan Armstrong wrote: (this is now kind of off the topic of radius but... ) Yes, it is a bit heavy What this is really doing is kind of sort of mimicking "private VLANs" in the Catalyst sense. Where each user in a VLAN cannot see each other, but they can all send traffic towards one assigned port... I am playing chicken with the Cisco development team. By the time I run into a hard limit somewhere, I am hoping they will have coded private VLANs into the Aironets Artur Hecker wrote: i don't know, but i would say execute an external program which reads a VLAN list file and attibutes and marks as used the next unused VLAN. but you will end up with #VLANs = #users... it's pretty heavy (pull all the VLANs from all APs to the switches) and quite limited, isn't it? ciao artur Dan Armstrong wrote: I know this idea is a bit whacked, but if anybody can think of a creative way I might be able to achieve it - I would be eternally grateful... We are authenticating wireless users from a Cisco Aironet (1100/1200). I know that I can pass back a VLAN to plop the user into, once authenticated. What I want to do is have radius keep a "pool" of VLANs, and each time a user is authenticated, they end up in the next VLAN. It would also have to return disconnected vlans back into the pool for reuse. Any thoughts? (If there is no relatively simple way to do this, I do have budget if anybody out there wants to help code it) :-) Thanks, Dan. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Dynamic VLAN assignment
well, i thought Dan was speaking about a new VLAN per user not per AP. this is possible with Cisco APs. as far as i know, 1200 and 1100 can do trunking. ciao artur Willey Kurt D wrote: I was under the impression that 1 AP = 1 VLAN. Has trunking been added? -Original Message- From: Artur Hecker [mailto:[EMAIL PROTECTED] Sent: Monday, May 24, 2004 5:40 PM To: [EMAIL PROTECTED] Subject: Re: Dynamic VLAN assignment i don't know, but i would say execute an external program which reads a VLAN list file and attibutes and marks as used the next unused VLAN. but you will end up with #VLANs = #users... it's pretty heavy (pull all the VLANs from all APs to the switches) and quite limited, isn't it? ciao artur Dan Armstrong wrote: I know this idea is a bit whacked, but if anybody can think of a creative way I might be able to achieve it - I would be eternally grateful... We are authenticating wireless users from a Cisco Aironet (1100/1200). I know that I can pass back a VLAN to plop the user into, once authenticated. What I want to do is have radius keep a "pool" of VLANs, and each time a user is authenticated, they end up in the next VLAN. It would also have to return disconnected vlans back into the pool for reuse. Any thoughts? (If there is no relatively simple way to do this, I do have budget if anybody out there wants to help code it) :-) Thanks, Dan. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Dynamic VLAN assignment
i don't know, but i would say execute an external program which reads a VLAN list file and attibutes and marks as used the next unused VLAN. but you will end up with #VLANs = #users... it's pretty heavy (pull all the VLANs from all APs to the switches) and quite limited, isn't it? ciao artur Dan Armstrong wrote: I know this idea is a bit whacked, but if anybody can think of a creative way I might be able to achieve it - I would be eternally grateful... We are authenticating wireless users from a Cisco Aironet (1100/1200). I know that I can pass back a VLAN to plop the user into, once authenticated. What I want to do is have radius keep a "pool" of VLANs, and each time a user is authenticated, they end up in the next VLAN. It would also have to return disconnected vlans back into the pool for reuse. Any thoughts? (If there is no relatively simple way to do this, I do have budget if anybody out there wants to help code it) :-) Thanks, Dan. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Artur Hecker artur[at]hecker.info - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: eap.cnf
in the current release version (0.9.3) - to my knowledge - there is no eap.conf, the eap configuration is rather directly in the radiusd.conf file. ciao artur BLANCA FERRERO RODRIGUEZ wrote: usually it's called 'eap.conf' and it is in the raddb dir. I have already searched in tha dir but I find no eap.conf!! I'm using freeradius 0.9.3 does it support PEAP? thanks bfr - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: eap.cnf
where you want it to: there is an INCLUDE line in your radiusd.conf. make it include YOUR file and it will work - provided that the server has the rights to read it. usually it's called 'eap.conf' and it is in the raddb dir. ciao artur BLANCA FERRERO RODRIGUEZ wrote: Could anyone tell me where the eap.cnf is supossed to be?in the raddb dir? thanks a lot bfr - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: access for eap/tls
ok, i've got it. obviously, i thought you were talking about a new possibility. always interested... :-) thanks artur Alan DeKok wrote: Artur Hecker <[EMAIL PROTECTED]> wrote: well, theortically, it needs a signing capacity (represented by an included extension) to do this. anyway, in my config the client certificates are _not_ signed by this one, they are - of course - signed by the private key of the CA... as ANY certificate ever issued. Ok... -- Artur Hecker artur[at]hecker.info - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: access for eap/tls
hi alan
Yes. See the tls{} configuration. It points to a server
certificate. The client certificates are signed with this certificate.
well, theortically, it needs a signing capacity (represented by an
included extension) to do this. anyway, in my config the client
certificates are _not_ signed by this one, they are - of course - signed
by the private key of the CA... as ANY certificate ever issued.
so, if you say you sign them by the server certificate, for me it means
that either root.pem and server.pem are the same files OR - more
generally - that a CA has signed a server a "special" certificate
permitting it to sign other certificates - which is actually quite
unusual but possible. so, i'm trying to understand what it is and what
would it provide...
Independently of the user & password existing in a database.
If you don't list usernames and passwords in a database, then the
server has no way of authenticating users... unless you use
certificates.
now i don't get it. what does the password has to do with that? we speak
about certificates, why would i configure a password?
i begin to think that we are terribly misunderstanding each other :-)
ciao
artur
--
Artur Hecker
artur[at]hecker.info
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: access for eap/tls
hi alan No, but where the client certificates are signed by the server certificate. oh.. so theoretically the server needs a "special" server certificate enabling it to sign something, right? (with the right extensions, etc.) In that case, the server (through the certificatge) has already said that the user is ok (by signing the users certificate.) Since that's done, there's not much point in checking a database, to see if the server knows about the user. yes ok. but if you just want to block a user for a while, you can still apply the rest of the authorization, right? i think my problem is that i don't really know who does what in the setup you present. rlm_eaptls checks the certificate - if it signed by the server's certificate than the user is granted access - independently of what? ciao artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: access for eap/tls
hi alan EAP-TLS. If the certificate supplied by the user is signed by the certificate FreeRADIUS is using, then it assumes that the user is OK. if i understand you correctly, you describe a case where the CA-root certificate and the server certificates are one and the same, don't you? why not but what is it exactly good for? ciao artur -- Artur Hecker artur[at]hecker.info - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: access for eap/tls
hi Alan Yes. The "users" file is just one form of controlling user access. You can store users in SQL, LDAP, or in signed certificates. i have a silly question: which signed certificates? do you have more info on this? ciao artur -- Artur Hecker artur[at]hecker.info - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: access for eap/tls
hi BLANCA FERRERO RODRIGUEZ wrote: is there any way that I can control this access of users with the users file although they have a correct cert? sotty to insist but could you tell me how to do this exactly? you should add a default behaviour which is reject, ie. a DEFAULT entry with Auth-Type = Reject e.g. and see the Fall-Through variable for a proper usage. logically, you will have to explicitly add _every_ user which is "known". now, for every pre-configured user, you can reject his access equally by adding an Auth-Type = Reject to his entry. there are examples in the 'users' file. attention though: the denial of users will be solely based on the User-Name content. strictly spoken, this is *not* what is certified in the certificate, it is merely data copied from the EAP-Identity field by the NAS. thus, if your wireless client decides to write a name of an authorized user into the EAP-Identity Response, he will be granted to access the system. to my knowledge, patches are needed to stop this (something has to check whether the User-Name equals something (CN?) in the certificate). ciao artur -- Artur Hecker artur[at]hecker.info - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: PEAP failure
hi do you have files in your authorization section of radiusd.conf? the lines for itself look correct to me but the debug log says clearly that something is wrong since mschap can't find the password. ciao artur Manuel Sánchez Cuenca wrote: Alan DeKok escribió: =?ISO-8859-1?Q?Manuel_S=E1nchez_Cuenca?= <[EMAIL PROTECTED]> wrote: rlm_mschap: No User-Password configured. Cannot create NT-Password. rlm_mschap: doing MS-CHAPv2 for lolo with NT-Password rlm_mschap: FAILED: No NT/LM-Password. Cannot perform authentication. PEAP (and mschap) needs access to a "good" clear-text password, or an nt-password to compare against the request. I have this in my users configuratin file: lolo User-Password == "entrar" Reply-Message = "Hola, lolo" ¿Is this correct? If the server doesn't have a password for the user, then it can't check the password the user supplied. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Artur Hecker artur[at]hecker.info - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Accounting and TTLS/User-Name
hi alan
thanks for the rapid pointers. some comments inline.
first of all, the following config directive:
...
does not seem to change anything in my case, in the Access-Accept
message sent by the server, the User-Name is still set to "anonymous".
Try instrumenting the server, to see if the user-name is set inside
of the tunnel.
i'm pretty sure it is, since the client does TTLS with an inner PAP auth
(secure W2 by alfa & ariss). by the way, what do you mean by
instrumenting the server - detailed log?
the problem is that we do not use the users file at all. our users are
rather stored in a remote SQL data base and I would like to add
something like a generic User-Name = %{User-Name} to the reply... but
when i add this to the SQL data base, the server takes this "as is" and
does not expand the variable (the access accept is sent for the
non-existent user called '%{User-Name}'.
Ah, yes. The SQL module doesn't do dynamic expansion. It probably
should...
In fact, the entire server should probably do that automatically.
ok, would it be difficult to add? where would you start? especially
talking SQL...
what can/should i do to have the tunneled user-name in the access-accept
in my case? we tried the expr but that didn't work out...
You should be able to have a post-auth module re-write the
username...
ok, i've thought about it but wanted first your opinion.
thank you
artur
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Accounting and TTLS/User-Name
hi
using FreeRADIUS Version 1.0.0-pre0, for host , built on Mar 26 2004 we
currently experience accounting user-name problems with both cisco APs
1100 and 1200.
first of all, the following config directive:
ttls {
# The reply attributes sent to the NAS are
# usually based on the name of the user
# 'outside' of the tunnel (usually
# 'anonymous'). If you want to send the
# reply attributes based on the user name
# inside of the tunnel, then set this
# configuration entry to 'yes', and the reply
# to the NAS will be taken from the reply to
# the tunneled request.
#
# allowed values: {no, yes}
use_tunneled_reply = yes
}
does not seem to change anything in my case, in the Access-Accept
message sent by the server, the User-Name is still set to "anonymous".
second of all, what works is to explicitly set the reply-item User-Name
to the actual name, e.g.:
artur User-Password == "hello"
User-Name = "artur"
in the 'users' file in %prefix%/etc/raddb (detail: and in eap {} to
activate the cisco firmware workaround cisco_accounting_username_bug =
yes). we had some difficulties to set the reply item to the respective
user automatically, like e.g. with %u, it really takes %u as value, but
well...
the problem is that we do not use the users file at all. our users are
rather stored in a remote SQL data base and I would like to add
something like a generic User-Name = %{User-Name} to the reply... but
when i add this to the SQL data base, the server takes this "as is" and
does not expand the variable (the access accept is sent for the
non-existent user called '%{User-Name}'.
what can/should i do to have the tunneled user-name in the access-accept
in my case? we tried the expr but that didn't work out...
thanks
artur
PS we also tried the 23.04.2004-snapshot with the same result.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Freeradius setting on Aironet 1100 AP
this is imho not a help service for cisco hardware. however, i'm sure that by opening a web browser and connecting to your AP 1100 address you will find all the answers you need, quasi automagically. just read the web pages of the ap, it is self-explanatory. ciao artur Aoun Shah wrote: Hi, I would like to configure my aironet 1100 AP for 802.1x. I want to know who to setup the AP to forward incoming packet to the Radius server, Precisely how to inform the AP about the Radius server and the secret key. As well as how to enable EAP on AP. Regards, Aoun. University of Stuttgart. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
