when the radius server authenticates the user, or whenever it is re-associated again to the AP, it will prompt the user to enter the password and location coordinates.

This may prove difficult if you are using the std. Windows supplicant since it caches credentials. We use WinXP with PEAP/MS-Chapv2 and I don't get reprompted for a password when it reauthenticates. I believe Vista has the capability to NOT cache wireless credentials. You perhaps could also have something delete the reg. key where the credentials are stored - that would force it to prompt again.. Perhaps you are using another supplicant that won't have this issue and that you could modify to prompt for additional information (loc.coord.)..?? Also, if location coordinates are generally known (10,10 = bldg 10/office 10 and 100,100 equals bldg 100, office 100), then how do you prevent users from entering the wrong coordinates in order to bypass your check? Even if your scheme isn't as simple as I described above, if the location coord. of a place is constant, over time people will learn the coordinates and they won't be useful as an additional security check. Are these numbers randomly generated or does each set of coordinates statically refer to a specific location (that's what I meant when I was asking the meaning of the coordinates)? If they're random, how will the information be given to the users?

Thereafter, the radius server will check on the password and the location coordinate. If either is not right, it will reject the connection.

The server will maintain a set of legitimate location coordinates in a file

and it will be updated by another program automatically.

Well, assuming you have a way to prompt, capture and send the "location coordinate" in the radius request, I would use rlm_perl during authorize and have it compare the location coordinate attribute to data in the file. You can easily return RLM_REJECT if the user hasn't specified a valid location coordinate. If you are planning to bury the information inside another attribute, you should check out attr_rewrite and hints as they have the ability to modify/create request attributes. As a caveat, this may not be the best approach though as I have only been using FR for a short time.

In the future, the coordinate may be derived by a system.

If you're trying to authorize by physical location, have you thought about controlling to which AP's they are authorized to connect (e.g., by Huntgroup-Name or NAS-IP-Address)? Also, Cisco AP's have a "dot11 location" config. stmt., that could be used to automatically pass static information as part of the radius requests (each AP would always pass the same static info though unless the config. was changed). If this would work for you, the user wouldn't need to enter anything (and they couldn't spoof the location coordinates). Does this help you?