[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: New XAUTH draft
Since I was partly responsible for launching this monster,
I'd like try to bat it back to the original point, with
some 'summation' of the discussion.
PKI is the right answer no doubt(apart from some CRL nightmares). We should
recommend PKI where possible.
The XAUTH 'concept' seems fine for folk migrating from traditional
remote-access, PPTP and raw L2TP implementations towards IPSEC protected
flows. Many of these installed remote-access servers will be using RADIUS
to centralise the authentication database.
If we use a 'low granularity' pre-shared secret for phase-1, then is should
probably be a MUST that the XAUTH method is challenge or token based.
Recent work in PPP/RADIUS land has come up with a great tool for Security
Gateways (SG) that need to support a raft of 'legacy' authentication modes,
which allows the SG to know nothing about which authentication method is
needed, or how it operates: EAP.
If we used something like EAP (or EAP itself preferably), the SG simply asks
the remote peer for an "ID", and then passes all the 'EAP Messages' from the
peer, via the RADIUS attribute 'EAP-Message' to the back-office RADIUS
server which then gets busy to talk to SecurID, OTP, etc. specialised
servers.
Taking this approach may mean the XAUTH become trivial for the SG to
implement, it just sends an initial 'Who are you' EAP message, and then
passes stuff straight from client to RADIUS server until the RADIUS server
says 'Access Accept'.
I am tempted to start suggesting we could solve some CRL issues using the
RADIUS model as well... another day :)
Steve.