Nicolas Williams writes: > IIRC the applicability statement of EAP would discourage use of EAP > clients in PAM modules: > > 1.3. Applicability > > EAP was designed for use in network access authentication, where IP > layer connectivity may not be available. Use of EAP for other > purposes, such as bulk data transport, is NOT RECOMMENDED.
No, that doesn't invalidate it. This usage isn't "bulk data transport." It's authenticating a user for network access. As far as the EAP server knows, it's talking to an EAP client that has a human demanding access behind it. The only difference is that instead of wiring the EAP client implementation directly to some UI with hard-coded function calls, we're intermediating the conversation through a local channel -- PAM -- that knows all about text-based UIs. It's really the same thing as intended. "Bulk data transport" in the above context refers to the almost irresistible urge that some people seem to have to layer one random protocol atop another. This has clearly happened to HTTP, and unless we defend it against those sorts of marauders, the same will happen to PPP, EAP, and other protocols. Because EAP runs on top of raw link-layer protocols (or even lower), without needing IP, there's a strong possibility that someone will want to define Request/Reply messages to send over things such as "default URL to open" or "background picture to display" or other such cruft. It's a nice simplex protocol that a method writer could hijack for transport of arbitrary data. EAP isn't a general-purpose transport protocol. It's a special-purpose transport for authentication mechanisms alone. > But yes, the two combinations of EAP/AAA/PAM that make sense are: > > - PAM modules that use EAP to authenticate users using suitable EAP > methods Yep. > - EAP/AAA servers that use PAM to validate user passwords, but of > course this only works for some EAP methods: the ones that transport > passwords to the server Of which there are intentionally close to zero. ;-} Actually, I suppose the OTP ones do that, but they're an outlier. Significantly, EAP has no provision for "normal" PAP-like operation. > > The point was that if the AAA infrastructure is robust, welding the > > AAA protocol of choice to EAP wouldn't have to be the design center > > anymore. > > I'm not sure I follow. What do you mean by "robust"? "Well-designed" > My understanding is that what's difficult about EAP/AAA is that too much > of the picture is underspecified. Specifically the whole > client/NAS/server interaction that keys the client<->NAS communications. Yes. > None of which is relevant to Bart's problem since there's no need for > client<->NAS comms in that case :) Of course. ;-} > > OTP makes that irritating, unless you have some sort of smart card > > that can do the work automatically without pestering the user. > > The idea is that roaming can be made to work without having to > re-authenticate every time. Of course this requires protocol specs. It works with the SRP-SHA1 method I wrote, but I didn't follow up on it. > > > Can we lift those bits and pieces into a framework? > > > > No. But they'd make good first customers of the framework to prove it > > out. > > Sigh. Having good customers is more than half the battle, I think. -- James Carlson, KISS Network <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
