RE: Cert enrollment?

["Bernard Aboba" <aboba@xxxxxxxxxxxxx>]

>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.