With Isabella looming I've gotten a few requests to set a realm to authenticate all should a downstream have stability issues. I need to set a specific realm to authenticate all incoming requests while having the others proxy as normal. Any ideas or experiences would be appreciated.
Brian -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Tuesday, September 16, 2003 10:39 AM To: [EMAIL PROTECTED] Subject: Freeradius-Users digest, Vol 1 #2312 - 7 msgs Send Freeradius-Users mailing list submissions to [EMAIL PROTECTED] To subscribe or unsubscribe via the World Wide Web, visit http://lists.cistron.nl/mailman/listinfo/freeradius-users or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of Freeradius-Users digest..." Today's Topics: 1. Re: dialup-admin patch2 (Ulrich Walcher) 2. Newsletter - Aktivierungslink ([EMAIL PROTECTED]) 3. Re: Https + RADIUS (Alan DeKok) 4. RE: [eap] non-wire related comments on eap-sim-11.txt ([EMAIL PROTECTED]) 5. RE: Wi-fi hotspot (Brynjar Hauksson) 6. Re: Radiusd service script + daemontools supervise (Alan DeKok) 7. RE: Wi-fi hotspot (Jeremy Davis) --__--__-- Message: 1 Subject: Re: dialup-admin patch2 From: Ulrich Walcher <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Organization: Date: 16 Sep 2003 15:22:40 +0200 Reply-To: [EMAIL PROTECTED] and here also... --- /usr/local/cvs/radiusd/dialup_admin/lib/sql/defaults.php3 2003-01-28 15:14:53.000000000 +0100 +++ /usr/local/dialup_admin/lib/sql/defaults.php3 2003-09-16 15:18:27.000000000 +0200 @@ -121,10 +121,10 @@ $link = @da_sql_pconnect($config); if ($link){ $res = @da_sql_query($link,$config, - "SELECT DISTINCT GroupName FROM $config[sql_usergroup_table];"); + "SELECT DISTINCT s.groupname FROM $config[sql_groupcheck_table] CROSS JOIN (SELECT DISTINCT u.groupname FROM $config[sql_groupreply_table] CROSS JOIN $config[sql_usergroup_table] u) as s;"); if ($res){ while(($row = @da_sql_fetch_array($res,$config))) - $member_groups[] = $row[GroupName]; + $member_groups[] = $row[groupname]; } else echo "<b>Database query failed: " . da_sql_error($link,$config) . "</b><br>\n"; Am Fre, 2003-09-12 um 16.08 schrieb Ulrich Walcher: > Oops, > forgot to add this one... > > OoLee > > --- /usr/local/cvs/radiusd/dialup_admin/lib/sql/defaults.php3 > 2003-01-28 15:14:53.000000000 +0100 > +++ /usr/local/dialup_admin/lib/sql/defaults.php3 2003-09-12 > 16:04:15.000000000 +0200 > @@ -121,10 +121,10 @@ > $link = @da_sql_pconnect($config); > if ($link){ > $res = @da_sql_query($link,$config, > - "SELECT DISTINCT GroupName FROM > $config[sql_usergroup_table];"); > + "SELECT DISTINCT c.groupname FROM > $config[sql_groupcheck_table] c CROSS JOIN $config[sql_groupreply_table] > r;"); > if ($res){ > while(($row = > @da_sql_fetch_array($res,$config))) > - $member_groups[] = $row[GroupName]; > + $member_groups[] = $row[groupname]; > } > else > echo "<b>Database query failed: " . > da_sql_error($link,$config) . "</b><br>\n"; > > > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > --__--__-- Message: 2 To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] Subject: Newsletter - Aktivierungslink Date: Tue, 16 Sep 2003 15:59:03 +0200 (CEST) Reply-To: [EMAIL PROTECTED] Hallo, Wenn sie diesen Newsletter erhalten wollen klicken sie bitte auf die Internet-Adresse. Falls sie diesen Newsletter nicht wollen l�schen sie einfach diese E-Mail. Aktivierungslink: http://www.1a-network.de/cgi-bin/newsletter/newsletter.cgi?id=mcsmail&email= [EMAIL PROTECTED]&key=WXIYX3q7yHnwU&action=aktiv Mit freundlichen Gr�ssen Newsletter-Team --__--__-- Message: 3 From: "Alan DeKok" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Https + RADIUS Date: Tue, 16 Sep 2003 10:16:52 -0400 Reply-To: [EMAIL PROTECTED] "JM Fernandez" <[EMAIL PROTECTED]> wrote: > Alan can you tell me the details on how the NAS gets the end user > username and password? It depends on the local implementation. > I'm planning to nake a web based login with an access point that > acts as a radius client. So have the NAS take the username & password from the web login form, and put them into a RADIUS packet. Am I missing something? Alan DeKok. --__--__-- Message: 4 Subject: RE: [eap] non-wire related comments on eap-sim-11.txt Date: Tue, 16 Sep 2003 17:20:44 +0300 From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Michael, Many thanks for your comments. I agree the document could use some=20 restructuring and clarification. It's a result of cumulative = revisioning,=20 and we haven't really thought about the structure since the beginning. It's very hard to structure the document so that you can understand everything by reading it once. I think we need to have a good overview section. It's not a good idea to duplicate the same information in several places of the document, so it may be hard to avoid referencing sections that follow the current section. > A1) please include real packet dumps, including encrypted data > with keys, to help people. We're planning to do that in appendix A.=20 =20 > A2) There is no per-attribute description/reference. > -> AT_VERSION_LIST for instance has no reference. ... > A4) The definitions of the attributes seems to be partially defined > only in the scenarios of sections 9-15. I would rather the=20 > attributes were defined seperately from the messages in which > they are used. Otherwise, it appears that one has to=20 > code per-message > marshalling/etc. It is hard to tell if this is true or not. >=20 Most of the attributes can be used in a certain message only, but there are attributes like AT_MAC that are general. Maybe we should have a separate section for the attribute definitions, like for example RFC2865. That would make the message definitions=20 simpler. > A3) paragraph 1 of 5.2. This conversation seems totally out of > place, and very confusing. OK. =20 > A5) It was not at all obvious that the AT_MAC is a keyed operation. > The last sentence of 8.1 says so, but I missed it at=20 > least twice, > thinking, but, it must be keyed, I remembered reading about it. >=20 > Maybe this is just the way that I read the document. Yes, it is a keyed operation, as described in section 8.1. > A5b) Annex A/B might be a little more detailed. > In particular, I think that you have chosen G to be SHA1, but > I'm not particularly certain. > Nor do I understahe what "m" is, or what the "optional=20 > user input" > is in this context. Please see other postings on the EAP mailing list about the PRF. > A6) split normative and informative references. OK. > A7) section 3, overview, para 3. > It seemed that this was the only place that the value=20 > of the Start > subtype was clearly stated. In addition, all protocol numbers are stated in=20 section 18 (IANA considerations). > A8) section 5.1, page 9,=20 >=20 > > In this case, the permanent username MUST be of the=20 > format "1imsi".=20 > =09 > It took me awhile to understand that the thing in quotes is a > pattern, not a string. Please remove "", or use another=20 > notation. OK > A9) section 5.1, page 9, para 4. > This seems really nebulous. >=20 Do you mean it's hard to understand if you don't know about re-authentication and IMSI privacy, which are discussed in later sections?=20 > A10) section 5.2, first paragraph. > It seems that you are putting the most complicated "gotcha" > at the beginning. At this point, I don't even know what you are > talking about yet! The "gotcha" is rationale for the feature. Maybe the first paragraph can be removed altogether. > A11) time-sequence diagrams. They are simply not useful to=20 > me. They just > seem to take lots of space. > They are useful when there are more than two parties. > A12) section 5.1, 5.2 and 5.3 should have *NO* mention of > re-authentication. Please describe the base protocol first,=09 > (including state machines), and then give the version that=20 > supports re-authentication. I agree it should be easy to understand the protocol in a general level by reading the first sections. But I'm not sure if we really need to first specify the base protocol only and cut corners in the specification of the Start messages for example. > A13) section 5.3, page 15, para 7. > " A received AT_PERMANENT_ID_REQ does not necessarily=20 > originate from " >=20 > The advice given seems very complicated and very dubious to me. > I believe that this must come out from the client state machine. The "advice" could be removed from the base description (and even omitted from state machine if we have such a thing), and we could discuss protection against active attacks on anonymity separately. > A14) section 6. > Caveat: I read this much less carefully.=20 > page 22, para 4: >=20 > " > Re-authentication identities are one-time identities. If=20 > the client=20 > does not receive a new re-authentication identity, it MUST use=20 > either the permanent identity or a pseudonym identity on the next=20 > authentication to initiate full authentication.=20 > " >=20 > Given that the identity is involved in the AT_MACs, are there > any cryptographic restrictions on the one-time identities? The identities are involved in key derivations in order to get implicit integrity protection by "binding" the derived keys to the identity string. I'm not sure if I properly understand your question, but I don't think there are any restrictions on the identities. >=20 > A15) section 7. basic format. > What if length =3D=3D 0. Malformed packet. > Then what? The current draft (section 15) specifies silent discard as the default operation in error cases, but we're going to change this in response to Glen's comments. If the client encounters a malformed packet, it sends an EAP-Response/SIM/Client-Error, to which the server replies with EAP Failure. If the server encounters a malformed packet, it issues EAP Failure. > A16) section 7. 0/127, 128-255 as "skippable". > I recommend that you adopt the terminology from IKEv2. > The high bit is the "critical" bit (or in this case, the > "non-critical" bit).=20 OK, that's another way to describe the same thing. > A17) section 8.2. AT_CHECKCODE. ...will be removed from the next version of EAP SIM. > A19) What if it is known that the encapsulator provides integrity=20 > protection and privacy? I.e. IKEv2? You'll still have to use AT_MAC, but you don't have to use IMSI privacy. If the encapsulator provides fast reconnect, you don't have to use EAP/SIM's re-authentication. >=20 > A20) section 10. > I'd like to see real numbers in the entire packet. > Hex dumps. > The code/id/Length/etc. break out seems to take way more white > space that it provides value. I think the hex dumps belong to the test vector section. The packets are not fixed length so hex dumps would be problematic except as examples. If we re-arrange the attributes to separate sections, then the descriptions of the messages will be shorter, but I think it is still useful to clearly state at least=20 the Subtype and Code for each message. > A21) re: AT_NEXT_PSEUDONYM, and I guess identities in general. > What about UTF-8? Internationalization? Should we specify that all identities contain UTF-8 encoded=20 ISO 10646 characters and refer to RFC2279? =20 > A22) section 18. > This seems to be the only place that there is a table of > values. I guess that is okay, but I found it hard to find. > I'd like to see a table with brief explanations of each=20 > attribue back in section 10 or earlier. Do you think a section with a separate subsection for each attribute would be good enough? For each message, the section that specifies the message can list the attributes that may, must and must not=20 be included. > A24) Annex B. I found it to be clear as MUD. I guess I don't > code very often to FIPS documents, are they all so obtuse? > C code for this PRF would be welcome, along with test vectors. > When I get mine working, I'll be happy to contribute them. This NIST specification really is very hard to follow. I think that we need to have pseudo-code too. I posted some test vectors on the list which we can include. Best regards, Henry --__--__-- Message: 5 From: "Brynjar Hauksson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>, "'Tom Emerson'" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Subject: RE: Wi-fi hotspot Date: Tue, 16 Sep 2003 21:28:12 +0700 Reply-To: [EMAIL PROTECTED] Hi Tom What prepaid system did you get? I've been searching for these systems with little success? Thanks in advance Kve=C3=B0ja / Best regards / = =E0=B8=94=E0=B9=89=E0=B8=A7=E0=B8=A2=E0=B8=84=E0=B8=A7=E0=B8=B2=E0=B8=A1=E0= =B8=84=E0=B8=B4=E0=B8=94=E0=B8=96=E0=B8=B6=E0=B8=87 Brynjar Hauksson ICQ# 15512204 -----Original Message----- From: [EMAIL PROTECTED] = [mailto:[EMAIL PROTECTED] On Behalf Of Tom = Emerson Sent: Tuesday, September 16, 2003 2:47 PM To: [EMAIL PROTECTED] Subject: Re: Wi-fi hotspot On Monday 15 September 2003 1:34 pm, Juliano Moises da Luz wrote: > Can someone point me some documentation about how to setup hotspot > authenticantion? As Alan mentioned, there is no one simple answer -- mainly because = there are=20 several ways of doing "a hotspot", some of which do not even NEED a = "radius"=20 server! > I need to setup a wi-fi hotspot and I am a little confused. I've = already > configured radius to authenticate users based on mac addresses, but = i'm not > sure this is the best way. A better place to begin is with the "Access point" you'll be using = [hereafter=20 referred to as a "NAS"] Some will do "all the work" for you [like the=20 Proxim/Orinoco AP-2500 that I have] while others will require a=20 behind-the-scenes approach [such as grabbing the least expensive AP at=20 Circuit City or Best Buy, then hanging it off of a used/refurbished = system=20 running linux to act as a "gateway"] Generally the NAS will be responsible for managing connections, IP = addresses,=20 and so on. The proxim that I have will intercept a web-request, put up = a=20 banner and a login screen, authenticate against an external RADIUS, and=20 enforce time limits if specified in the "reply" packet. Using a program = such=20 as NOCAT will let you do the same in a roll-your-own environment. The next question to consider is "are users going to pay for access?" = For=20 instance, in a coffee-shop environment, it might make sense to "give = away"=20 access time (i.e., don't charge at all) and use it as a "draw" to get=20 customers into the building. [otoh, coffee-house clientelle are often=20 "leeches" in that they will gladly sit around all day using your = internet=20 connection without a hint of a purchase...] On the third hand, however, = folks who hang out at a coffee house are "regular" customers, so a = "monthly=20 rate" is often a good compromise. Other locations, such as an airport or hotel, have a much more "fluid"=20 clientelle -- you'll never see the same guy twice in a month [unless = he's the=20 pilot...] so these people you want to hit with a per-hour rate, or even=20 per-quarter-hour [heck, T-mobile charges BY THE MINUTE] The next question is HOW are they going to pay? cash is always the = easiest,=20 but may lead to difficulties depending on the location [that airport=20 again...] Credit cards billed-as-used are great, but may require a = merchant=20 account [which is OK if you are the owner of the location -- you're = probably=20 already set up for such...] Again, the NAS may play a role in this -- = the=20 Proxim can be configured to talk to an "industry standard" [hah!] = website and=20 thus manage the billing for you. With a roll-your-own, well, you'll be=20 rolling it anyway, might as well build a custom merchant/CC gateway = while=20 you're at it... In my case I opted for a pre-paid/pre-printed "card" system. I generate = a=20 number of user ID's and passwords, each with an hour's worth of "time"=20 associated with it, then print regular business-cards with the logo, = user ID,=20 and password. Since these are stored in a locked drawer behind the = counter,=20 I don't need fancy "scratch-off" style cards. One "hotspot-in-a-box" = vendor=20 actually has a thermal printer included with the setup -- pressing a = button=20 generates a user ID/password "on the fly" and allocates some amount of = time=20 to it. I've ALSO set up an interesting compromise to the aformentioned "leech"=20 problem: I've set up a "counter" that tallies time on a per-MAC basis, = with a=20 limit of 15 minutes per day. This actually uses a set user ID/password=20 combo, which is actually included in the login banner. This lets people = use=20 it seemingly like a promo ("with the purchase of a drink, you get...") = yet=20 doesn't require extensive configuration on my part [i.e., building=20 potentially hundreds of "15 minute user ID's"] [search the archive for=20 details -- I have posted the configuration items neccesary to do this] There are probably lots of other things that can be brought up for = discussion,=20 but notice VERY LITTLE of the above discussion really "needs" (or = involves)=20 Radius -- the NAS/AP can be configured with a list of known acceptible = MAC=20 addresses and/or set for "billing" people via a credit card, or you may = be in=20 a "don't care" situation in which case you really only need a "typical"=20 consumer/home "wireless access point" set with a known SSID (and with a = DHCP=20 server enabled internally...) About the only thing you'll need a radius = server for is managing "pre-printed" access cards (in which case you'll=20 really be managing a mysql or postgresql database...) or "monthly=20 subscribers" --=20 Yet another Blog: http://osnut.homelinux.net --__--__-- Message: 6 From: "Alan DeKok" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Radiusd service script + daemontools supervise Date: Tue, 16 Sep 2003 10:35:40 -0400 Reply-To: [EMAIL PROTECTED] "simon mackey" <[EMAIL PROTECTED]> wrote: > When I boot up I can see the message "Starting radiusd [OK]" amongst all > the other services like httpd, etc., so I presume it's running, but when I > log in and type "lsof -i" at the command line I don't see any radiusd > processes running :( 'ps' is the usual command to use. 'lsof' does something else. > I would reallllly appreciate it if someone would take me through how to get > radiusd to start at boot time (with daemontools also monitoring it without > me having to type supervise /var/svc/radiusd every time I reboot)? The 'doc' directory has documentaion on setting up daemontools. As for getting it to run on boot, that's a function of your local OS. Read it's documentation, and look at the scripts for the other programs which *do* run on boot. Alan DeKok. --__--__-- Message: 7 From: "Jeremy Davis" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Subject: RE: Wi-fi hotspot Date: Tue, 16 Sep 2003 10:38:23 -0400 Reply-To: [EMAIL PROTECTED] I recommend the Colubris CN3000 and the Zyzel 4000 for multi-AP = deployments and the AP2500 or StarOS for single AP deployments. It is = relatively easy to build a prepaid card engine due to the modular = approach of FreeRadius. I have built one, and have another customer in = the queue for this type of application. If you need help contact me = off-list. Jeremy -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Brynjar Hauksson Sent: Tuesday, September 16, 2003 10:28 AM To: [EMAIL PROTECTED]; 'Tom Emerson' Cc: [EMAIL PROTECTED] Subject: RE: Wi-fi hotspot Hi Tom What prepaid system did you get? I've been searching for these systems with little success? Thanks in advance Kve=C3=B0ja / Best regards / = =E0=B8=94=E0=B9=89=E0=B8=A7=E0=B8=A2=E0=B8=84=E0=B8=A7=E0=B8=B2=E0=B8=A1=E0= =B8=84=E0=B8=B4=E0=B8=94=E0=B8=96=E0=B8=B6=E0=B8=87 Brynjar Hauksson ICQ# 15512204 -----Original Message----- From: [EMAIL PROTECTED] = [mailto:[EMAIL PROTECTED] On Behalf Of Tom = Emerson Sent: Tuesday, September 16, 2003 2:47 PM To: [EMAIL PROTECTED] Subject: Re: Wi-fi hotspot On Monday 15 September 2003 1:34 pm, Juliano Moises da Luz wrote: > Can someone point me some documentation about how to setup hotspot > authenticantion? As Alan mentioned, there is no one simple answer -- mainly because = there are=20 several ways of doing "a hotspot", some of which do not even NEED a = "radius"=20 server! > I need to setup a wi-fi hotspot and I am a little confused. I've = already > configured radius to authenticate users based on mac addresses, but = i'm not > sure this is the best way. A better place to begin is with the "Access point" you'll be using = [hereafter=20 referred to as a "NAS"] Some will do "all the work" for you [like the=20 Proxim/Orinoco AP-2500 that I have] while others will require a=20 behind-the-scenes approach [such as grabbing the least expensive AP at=20 Circuit City or Best Buy, then hanging it off of a used/refurbished = system=20 running linux to act as a "gateway"] Generally the NAS will be responsible for managing connections, IP = addresses,=20 and so on. The proxim that I have will intercept a web-request, put up = a=20 banner and a login screen, authenticate against an external RADIUS, and=20 enforce time limits if specified in the "reply" packet. Using a program = such=20 as NOCAT will let you do the same in a roll-your-own environment. The next question to consider is "are users going to pay for access?" = For=20 instance, in a coffee-shop environment, it might make sense to "give = away"=20 access time (i.e., don't charge at all) and use it as a "draw" to get=20 customers into the building. [otoh, coffee-house clientelle are often=20 "leeches" in that they will gladly sit around all day using your = internet=20 connection without a hint of a purchase...] On the third hand, however, = folks who hang out at a coffee house are "regular" customers, so a = "monthly=20 rate" is often a good compromise. Other locations, such as an airport or hotel, have a much more "fluid"=20 clientelle -- you'll never see the same guy twice in a month [unless = he's the=20 pilot...] so these people you want to hit with a per-hour rate, or even=20 per-quarter-hour [heck, T-mobile charges BY THE MINUTE] The next question is HOW are they going to pay? cash is always the = easiest,=20 but may lead to difficulties depending on the location [that airport=20 again...] Credit cards billed-as-used are great, but may require a = merchant=20 account [which is OK if you are the owner of the location -- you're = probably=20 already set up for such...] Again, the NAS may play a role in this -- = the=20 Proxim can be configured to talk to an "industry standard" [hah!] = website and=20 thus manage the billing for you. With a roll-your-own, well, you'll be=20 rolling it anyway, might as well build a custom merchant/CC gateway = while=20 you're at it... In my case I opted for a pre-paid/pre-printed "card" system. I generate = a=20 number of user ID's and passwords, each with an hour's worth of "time"=20 associated with it, then print regular business-cards with the logo, = user ID,=20 and password. Since these are stored in a locked drawer behind the = counter,=20 I don't need fancy "scratch-off" style cards. One "hotspot-in-a-box" = vendor=20 actually has a thermal printer included with the setup -- pressing a = button=20 generates a user ID/password "on the fly" and allocates some amount of = time=20 to it. I've ALSO set up an interesting compromise to the aformentioned "leech"=20 problem: I've set up a "counter" that tallies time on a per-MAC basis, = with a=20 limit of 15 minutes per day. This actually uses a set user ID/password=20 combo, which is actually included in the login banner. This lets people = use=20 it seemingly like a promo ("with the purchase of a drink, you get...") = yet=20 doesn't require extensive configuration on my part [i.e., building=20 potentially hundreds of "15 minute user ID's"] [search the archive for=20 details -- I have posted the configuration items neccesary to do this] There are probably lots of other things that can be brought up for = discussion,=20 but notice VERY LITTLE of the above discussion really "needs" (or = involves)=20 Radius -- the NAS/AP can be configured with a list of known acceptible = MAC=20 addresses and/or set for "billing" people via a credit card, or you may = be in=20 a "don't care" situation in which case you really only need a "typical"=20 consumer/home "wireless access point" set with a known SSID (and with a = DHCP=20 server enabled internally...) About the only thing you'll need a radius = server for is managing "pre-printed" access cards (in which case you'll=20 really be managing a mysql or postgresql database...) or "monthly=20 subscribers" --=20 Yet another Blog: http://osnut.homelinux.net -=20 List info/subscribe/unsubscribe? See = http://www.freeradius.org/list/users.html --__--__-- - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html End of Freeradius-Users Digest - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
