RE: User-level Authentication Mechanisms for IPsec

["Bernard Aboba" <aboba@xxxxxxxxxxxxx>]

>If this is the case, you are very close to being able 
>to deploy user certificates. In which case, in my opinion, 
>you do not need to support legacy authentication systems.

As discussed in the paper, PKI deployment is a continuum,
starting from a firm with no PKI capabilities that is only
using legacy methods, to a firm that has deployed user
certificates, often with smartcards. 

Along this continuum there are a number of transition
points. This can include:

a. Supporting machine certificates on the server, but
legacy auth on the client. 

b. Supporting machine certs on both client and server,
with legacy user auth.

c. Supporting user certs on the client, and a machine
cert on the server. At this point there is no need for
legacy user auth. 

As noted in the draft, we need to be more explicit about
which transition points we are attempting to enable.

The draft talks about providing transition support at
step a, using the Hybrid concept. Thus, it is attempting
to provide transition benefits at step a and *does not*
assume user certificates, or even a machine cert. on the
client. 

Getting to point b, with machine certs on both client and
server, allows the use of IKE w/certificate auth, but in
this stage it is still conceivable that the customer would
want legacy user authentication, if only so that they can
know who the user is and apply apropriate authorizations.

It is only in step c that legacy user auth can be discarded; 
and this step frequently requires *significant* additional 
work beyond step b. Step c is frequently implemented via 
deployment of smartcards. This may mean that the firm 
has to revise their badging system so as to provide 
combined smartcard/badges. Whereas in step b
all that may be required is a machine auto-enrollment.