Nicolas Williams writes:
> > It'd be nice to have a PAM module that depends on a protocol-neutral
> > AAA infrastructure. That infrastructure (just like the existing name
> > service switch) can then have plug-ins for the various AAA clients
> > you'd want to have.
>
> But since PAM is already a pluggable interface multiple modules should
> also work.
It's a pluggable interface, but I'm not at all sure it's really the
droid you're looking for.
PAM is oriented around sending messages to humans, with a very
command-response sort of design. I'd like to see how it could be used
for a more protocol-oriented usage, where there are timers,
retransmits, and other things happening, but that sounds like a bit of
a strange duck to me.
> > > I think that makes a lot of sense.
> > >
> > > Plus an EAP client, and an EAP authenticator and common EAP methods.
> >
> > Yes. Those sound to me like AAA plug-ins.
>
> EAP clients are AAA-agnostic. EAP servers aren't.
There are several dimensions to this.
Take PPP for example. You have in short:
remote <---PPP---> local <---AAA---> server
There are at least two basic modes of operation here: if PPP is using
CHAP or PAP for authentication (which is by far the most common
usage), then 'local' uses the AAA facilities itself to authenticate
against the server.
If PPP is using EAP, then the actual EAP client is the system labeled
'remote', and it needs to know about the method in use, but not the
AAA. 'local' just does retransmission and some basic EAP set-up
(Identify is common), and otherwise bridges between PPP and AAA. The
'server' needs to have the EAP backends or needs to proxy to someone
who does.
The EAP server itself doesn't actually need to be AAA-specific.
Provided a decent AAA infrastructure, it could just use the AAA system
like a transport -- just as it would use any transport, including PPP,
to reach the EAP client.
> I'm not sure I
> understand EAP authenticators well enough to say; IIRC for
> authenticators it depends on the EAP method being used.
Yes.
The last I looked at all of this, the EAP working group was busy
trying to make the EAP-over-Foo task (needed for AAA) as difficult as
possible by (in my opinion) overspecifying the solution space. I'm
not sure what the current state might be.
Nicolas Williams writes:
> We should seek funding for a project in this space, unless we already
> have it (do we?).
Not that I know of.
> With WPA the lack of AAA support in Solaris is becoming painful.
It was bad enough back when we implemented Mobile IP and PPP without
it.
--
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
