Advice on simple password implementation?

[Alan DeKok]

On Aug 14, 2019, at 8:18 AM, Ted Hyde (RSI) <thyde at rndstudio.com> wrote:
> 
> Greets! This a little FR-related, and a bit more system advice-related. The end result is possibly to implement on FR, of course.

  Not always, but usually, yes.

> I typically implement FR in an EAP-TLS (note just TLS, not tunneled-TLS) scenario where client certificates are manually installed on the supplicants (such as tablets) because I have the luxury of controlling that. It works fine and although it may not be a perfect practice if revoking is necessary, it makes the deployment and control for field personnel consistent and dependable. It keeps by blood pressure low, which is amazing for IT components.
> 
> I have a different situation where the installation has a lot of transient supplicants (guest staff coming and going) and the connection path was simply to go WPA and share the key (via secure post-it, of course) with that guest staff. I don't love this setup, but it does work. If the key becomes compromised, we have to go in and change in each NAS (the access points / NAS are Cisco autonomous AP's - no WAP since they are spread out further and across different logical nets). I have a little automatic script that can do this, but it ends up giving the script administrative access to the NAS's so it's a possible security concern.
> 
> To make matters worse, I will be leaving the setup after it is done, and I have a concern that certificates may expire after my departure causing a traditional EAP-TTLS option to fail, else that would also be an option.

  That makes it more difficult, yes.

> Is there a practical configuration to set up the AP's (not sure if EAP-TTLS can be re-written to ignore certificates, just use a username/password?) to create a system that would generate a [daily] random password that could be given to a guest staff, for which they can quickly enter and gain access, but that credential changes on a recurring basis? I can write the credential assignment portion separately, and store it in db/file for FR, but it's the config of FR that I don't know about.

  TBH, this is what captive portals are for.  They're ugly, but standardized.  Which means documented, etc.

> I recall having visited some other vendor sites that had a captive portal that did a similar thing, but I think they did that at the L3 level, not at the initial AAA level on the NAS. (As in the wireless was completely open, and they controlled routing, not connection). Since I would have a working FR setup, I would prefer to not need to have another application layer to handle just one client purpose.

  If you're set on avoiding a captive portal, I'd suggest EAP-PWD.  It doesn't use certificates.  But I'm not sure that Windows supports it.

  Alan DeKok.