[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Cert enrollment?
>Although the charter isn't phrased in these terms, let's be real. The
>primary area of interest for ipsra is sites with RADIUS databases, with
>authentication via passwords or SecurID, and probably via PPP-grade
>challenge/response. If those mechanisms can handle these scenarios, we
>may have a winner.
I'd also add that having heard these kind of requests from customers
for several years, it is never as simple as "only doing PPP and
SecurID." There are a lot of extended authentication vendors out
there who will want to be supported as well. So you either adopt
an existing framework (GSS_API, SASL, EAP) that is extensible,
with existing libraries and documentation, or you end up inventing
another one. Having had to try to explain to a developer why the IETF
has three frameworks (and how not to have to write the same
code 3 times!), I *really* don't want another framework.
At this point we've made some progress on the framework
explosion issue because SASL and EAP can now use GSS_API methods,
(see SASL GSS_API and EAP-GSS specifications). This means that
if you an authentication method in GSS_API you get the others for
free. So from where I sit, GSS_API looks like the most fundamental
of the frameworks, but I could easily be convinced to throw in
one or two more existing ones if that would make people happy.
What I don't want is yet another one.