Re: More on certificate enrollment...

[Yaron Sheffer <yaron.sheffer@xxxxxxxxxxxx>]

Hi Bernard,

As this is an interim solution, we cannot ask for more ID options than are
supported by IKE: DN, FQDN, user-FQDN (=email address), or did I miss anything?
But the verification of the validity of the Email address (or
enterprise-specific DNS entry) is an administrative thing, only defined by
Verisign's CPS. In our case, validation of the user's credentials should only
depend on the authentication server with which the user communicates, and which
proxies the enrollment request (note: I am assuming the getcert/PIC
architecture). The server's policy may or may not mandate validation of an
Email address or DNS name.

I am surprised by the suggestion to have the cert Emailed to the user (as is
currently done by some CA's). This is certainly not the right way to go in a
remote access scenario.

A more interesting question in my mind is whether any of the existing
enrollment protocols can be extended to support in-line user authentication by
a trusted proxy authentication server. Any ideas?

Thanks,
    Yaron

Paul Krumviede wrote:

> --On Thursday, 15 June, 2000 11:00 -0700 Bernard Aboba
> <aboba@xxxxxxxxxxxxx> wrote:
>
> >
> >> It's a migration path because the underlying IKE software is completely
> >> certificate-based.  Users can convert one at a time; the over-the-wire
> >> IKE and the servers don't have to be touched when you start using
> >> PKI-based permanent certificates.  Furthermore, once all of your users
> >> have converted, you can delete the old software and be left with no
> >> vestigal pieces of code.
> >>
> >
> > So essentially we are addressing the issue of certificate enrollment
> > here. That is a good thing. In fact, I wish we would spend more time
> > discussing this instead of the interminable L2TP vs. IPSEC
> > tunnel mode flame wars. Boy, is that getting old.
> >
> > For example, I am curious about the level of authentication that needs
> > to be provided for various certs.
>
> this occasionally gets discussed in PKIX, in terms of what a CA should
> verify. is that what you mean by authentication?
>
> > My understanding is that a level 1
> > cert as defined by Verisign requires that the certificate provider verify
> > that the user can receive email at the userID included in the cert.
>
> I thought the actual check was that the email address be unique,
> apparently in the sense that it hasn't been used as the subject (or
> altSubjectName?) previously. I gather that if the requestor can't
> receive email at the address then they won't get the notification
> to go pick up the cert, but I think that the cert request will have
> been processed and a certificate created.
>
> > If
> > the cert provider is the same as the email provider, this
> > assurance can be provided by having the user authenticate themselves
> > via the Web or other method. Alternatively, if the cert
> > provider is not the email provider, the cert can be sent to the user by
> > e-mail. Are we always assuming that the cert provider and email
> > provider will be the same for purposes of IPSRA? For example, are
> > we trying to support access to the Bigco.com Intranet from users
> > who identify themselves as bigcouser@xxxxxxx rather than
> > fred@xxxxxxxxx?
>
> Working for a company that likes to change names and acquire
> other companies, I'm not sure that we should make such an
> assumption.
>
> -paul

begin:vcard 
n:Sheffer;Yaron
tel;cell:+972-51-628922
tel;work:+972-3-765-8922
x-mozilla-html:TRUE
url:www.radguard.com
org:Radguard
adr:;;Atidim Technology Park, Bdg #4;Tel Aviv;;61581;Israel
version:2.1
email;internet:yaron.sheffer@xxxxxxxxxxxx
title:Group Leader, Technologies
fn:Yaron Sheffer
end:vcard