[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Radius authentication and client configuration
>
> > If EAP needs to be fixed, this is the right time. It is
> > currently sitting on
> > the IESG's pending list and if changes are needed we need to
> > bring them up. I
> > personally would like to see EAP be used in a wide variety of
> > access schemes
> > (i.e. PPP, SOCKS, IPSEC, Voice/IP, etc).
>
> For a start it shouldn't be a "PPP" method if you are trying to make it
> available to other working groups and those working groups must have had
> some input before the document went out to the IESG.
Agreed. Unfortunately I just recently started pushing harder on EAP within
other WGs. I like the concept and, as an ex-router developer, the thought of
not having to add proprietary code to an embedded device is really nice. It
allows authentication to occur end-to-end between the user and the
authentication server.
As you stated in your previous mail (I believe it was you) it does require
that the token/smart card vendor support the transport (RADIUS/DIAMETER) on
their authentication server.
As for getting input from other groups, the draft did go out for last call and
did not receive any comments besides a small one regarding UTF-8. Just because
it is a proposed standard does not mean that we cannot change it slightly in
order to meet other WG's needs.
PatC
References: