The connection is restricted. Users from known organisations can register
for access to particular services with us using their own LIDs.
Registrations go through an online approval process where service delivery
owners can allocate appropriate levels of access. We prefix the LIDs with an
org code to guarantee uniqueness, however this is transparent to the users
(since we can use the source IP address to determine the organisation).
Users authenticate using their own LIDs and registered password. The
authentication details are stored in a X500 directory. Password expire and
can be changed any time, etc.
Ultimately we'd like to move to client SSL and smartcards (or possibly
floppy disks as tokens) to allow for simplified infrastructure and location
independant access. But we're waiting on SC readers to be everywhere :-). On
the other hand the complexity around the Infrastructure bit of PKI???? At
the moment I'm inclined to think that no-one shares certs and we all become
our own root CA!!!
----- Original Message -----
From: "Derek.Browne" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, March 11, 2001 3:48 AM
Subject: RE: Client certificates: Key store per workstation, not per user?
> Hi,
>
> This is an interesting problem....You said something that I just don't
> understand...The remote users from other organizations could use their own
> organizations logonIds to id themselves to your Organization.
>
> Do you mean that your org didn't have any list of acceptable users? That
> the authentication was based on the remote IP alone (which might be fine
if
> the connection was restricted to come from a known safe VPN)?
>
> Later,
> derek
>
>
> --
> Derek J. Browne
>
>
>
> ::-----Original Message-----
> ::From: [EMAIL PROTECTED]
> ::[mailto:[EMAIL PROTECTED]]On Behalf Of bruce cartland
> ::Sent: Saturday, March 10, 2001 2:58 AM
> ::To: [EMAIL PROTECTED]
> ::Subject: Re: Client certificates: Key store per workstation, not per
> ::user?
> ::
> ::
> ::So users sharing passwords are at least limited to within an
organisation.
> ::Sounds perfectly reasonable.
> ::
> ::I don't know the ins and outs of your client base but I did a similar
> ::project a couple of years ago before client side SSL was
> ::feasible. Since all
> ::our clients were inter-gov agencies we put in a gateway to gateway VPN
> ::solution over the internet. We then got the reverse proxy to forward the
> ::incoming IP address so we could tell (& validate) where the users were
> ::coming from. This also meant we could tailor content to the organisation
> ::prior to knowing who the user was. It also meant users could use their
own
> ::organisation logonids to identify themselves to us - something that was
> ::appreciated.
> ::
> ::One limitation we had was not being able to touch client
> ::machines. Also all
> ::executable content was blocked at various firewalls so a Java applet
> ::solution was out of the question. Pity because we'd already prototyped
> ::applet/smartcard authentication. Another option was using
> ::one-time password
> ::technology (something we use for our own staff). This would mean 0
client
> ::installs and reduces the risk of password sharing (it would also mean
> ::issuing the token generators to users).
> ::
> ::I like the idea of installing the keystore/cert at the workstation
level.
> ::Means less hassle with VPN infrastructure or cert per user. You would,
> ::howver, be putting the onus onto the administrators (how many per org?)
to
> ::do the right thing and not install the keys/certs elsewhere.
> ::
> ::Since you can install stuff on client machines I would think the way to
go
> ::would be to install an IE extension. Your extension could then do its
own
> ::thing (using OpenSSL :-) and encrypt the data itself - don't even
> ::need SSL.
> ::Of course it would have to hold the PIN/passphrase to unlock the
> ::workstations private key... and you'd want to make it hard to copy the
> ::keystore and extension to another machine. It would be nice if the
server
> ::can initiate a standard client SSL request that invokes your extension
> ::without prompting the user for a cert (then again maybe it can?).
> ::
> ::
> ::----- Original Message -----
> ::From: <[EMAIL PROTECTED]>
> ::To: <[EMAIL PROTECTED]>
> ::Sent: Saturday, March 10, 2001 4:55 AM
> ::Subject: RE: Client certificates: Key store per workstation, not per
user?
> ::
> ::
> ::> I need to use the client certificates with IE. I will have a
> ::look into the
> ::> crypte API.
> ::>
> ::> Thanks
> ::> rainer
> ::>
> ::> -----Original Message-----
> ::> From: Greg Stark [mailto:[EMAIL PROTECTED]]
> ::> Sent: Freitag, 9. März 2001 18:34
> ::> To: [EMAIL PROTECTED]
> ::> Subject: Re: Client certificates: Key store per workstation, not per
> ::> user?
> ::>
> ::>
> ::> Rainer,
> ::>
> ::> You write,
> ::> "...Second, I think, that without client-certificates
> ::> man-in-the-middle attacks are possible, using tools like dsniff."
> ::>
> ::> and this is not correct. As long as the client does proper
> ::checking of the
> ::> server certificate AND you use SSLv3 or higher, you are not
> ::vulnerable to
> ::> MITM attacks.
> ::>
> ::> I think I understand what you are trying to do but are you writing
> ::your
> ::> own, custom, client software, or are you using MS IE? If the latter, I
> ::don't
> ::> know how hard it would be to implement what you want, but
> ::another resource
> ::> you might want to query is the MS Crypto API mailing list archives
> ::> (http://discuss.microsoft.com/archives/cryptoapi.html). You might
search
> ::on
> ::> CRYPT_MACHINE_KEYSET to get some posts on similar sorts of issues.
> ::>
> ::> _____________________________________
> ::> Greg Stark
> ::> Ethentica, Inc.
> ::> [EMAIL PROTECTED]
> ::> _____________________________________
> ::>
> ::>
> ::>
> ::> ----- Original Message -----
> ::> From: <[EMAIL PROTECTED]>
> ::> To: <[EMAIL PROTECTED]>
> ::> Sent: Friday, March 09, 2001 10:56 AM
> ::> Subject: RE: Client certificates: Key store per workstation,
> ::not per user?
> ::>
> ::>
> ::> > My project is a inter-government project over the internet, with
2400
> ::> > independent organizations in the first phase. Authentication is a
> ::> important
> ::> > issue. We agreed, that smart cards would be a good solution, but are
> ::> beyond
> ::> > the timescale of the projekt, because we cannot implement that for
> ::10000+
> ::> > users within 6 month. Besides, there is a country-wide
> ::project going on,
> ::> > that targets this issue with a 2-year timeframe.
> ::> >
> ::> > UserID and password over SSL are considered as insufficient. First,
> ::> because
> ::> > it is difficult that passwords are kept secret properly in this
> ::> environment.
> ::> > AKAIK, this is still the security threat #1. Second, I think, that
> ::without
> ::> > client-certificates man-in-the-middle attacks are possible,
> ::using tools
> ::> like
> ::> > dsniff.
> ::> >
> ::> > Hence, lacking smart cards, an authentication scheme using userid/pw
> ::plus
> ::> > client certificates werde devised. An administrator can only
download
> ::and
> ::> > install a certificate, a user can only access the application
> ::using the
> ::> > userid. Well, the user could export the certificate and post it on a
> ::> public
> ::> > server, but that is definitely a different thing that just
> ::writing down
> ::> the
> ::> > password on the back of the mousepad.
> ::> >
> ::> > The authentication service will check the relationship between
> ::certificate
> ::> > and userid. Ideally a user should be able to work from any PC
> ::certified
> ::> for
> ::> > her organization, but nowhere else. In this sense, we do not use
> ::personal
> ::> > certificates, but 'organizational' certificates, as a user may use
any
> ::> > certificate within the organization. We cannot rely on all
> ::organizations
> ::> > having roaming profiles, where all users would have access to the
> ::> > certificate without depending on the location.
> ::> >
> ::> > The question is the CertStore. To reduce the administrative
> ::burden, only
> ::> one
> ::> > certificate per workstation would suffice. Kind of
> ::> "c:\windows\profiles\all
> ::> > users\keystorefile".
> ::> >
> ::> > I would like to your opinion
> ::> > Rainer
> ::> >
> ::> > -----Original Message-----
> ::> > From: bruce cartland [mailto:[EMAIL PROTECTED]]
> ::> > Sent: Freitag, 9. März 2001 14:50
> ::> > To: [EMAIL PROTECTED]
> ::> > Subject: Re: Client certificates: Key store per workstation, not per
> ::> > user?
> ::> >
> ::> >
> ::> > I thought Kerberos was symmetric?
> ::> >
> ::> > I'd like to hear more on the requirement(s)? Identify workstations
for
> ::> > audit? Identify users? Not use clear text?
> ::> >
> ::> > I'd love to hear opinion but client side certs for
> ::workstations sounds a
> ::> bit
> ::> > strange. The workstation would have to store the keystore/cert
unlock
> ::code
> ::> > somewhere. If you just want to identify the workstation (for audit
> ::> > presumably) the server can tell the IP address (can be
> ::spoofed though).
> ::> > Perhaps it would be better if the server picked up the MAC address
of
> ::the
> ::> > workstation? (haven't found a good way of doing that without running
> ::some
> ::> > kind of service on the workstation the server can talk back to -
which
> ::can
> ::> > run into problems with routers/proxies/NATs between the server &
> ::client).
> ::> >
> ::> > User identity + encryption can be done just using userid/pwd +
server
> ::SSL.
> ::> >
> ::> > What about using smartards & client side certs for mobile users?
> ::> >
> ::> > I've been told of a nice (commercial) implementation which
> ::extends IE or
> ::> > netscape where the server can initiate a client cert request over
> ::http/s.
> ::> > The browser prompts the user to select the keystore/cert,
> ::etc. These may
> ::> be
> ::> > stored on a smartcard. I'm hoping to get a demo soon. I'll be very
> ::> > interested to here about alternatives.
> ::> >
> ::> > regards
> ::> > bc
> ::> > ----- Original Message -----
> ::> > From: <[EMAIL PROTECTED]>
> ::> > To: <[EMAIL PROTECTED]>
> ::> > Sent: Friday, March 09, 2001 11:48 PM
> ::> > Subject: RE: Client certificates: Key store per workstation, not per
> ::user?
> ::> >
> ::> >
> ::> > > Does it work in a browser-only environment? Would
> ::communicator support
> ::> it?
> ::> > >
> ::> > > Rainer
> ::> > >
> ::> > > -----Original Message-----
> ::> > > From: Jean-Marc Desperrier
> ::[mailto:[EMAIL PROTECTED]]
> ::> > > Sent: Freitag, 9. März 2001 13:31
> ::> > > To: [EMAIL PROTECTED]
> ::> > > Subject: Re: Client certificates: Key store per workstation, not
per
> ::> > > user?
> ::> > >
> ::> > >
> ::> > > [EMAIL PROTECTED] wrote:
> ::> > >
> ::> > > > I would like to use SSL with client certificates, but
> ::assign them to
> ::> > > > workstations instead of users.
> ::> > >
> ::> > > I think you should watch what can be done with kerberos for
> ::this kind
> ::of
> ::> > > feature.
> ::> > >
> ::> > > > Does someone know, if there is a way to install a
> ::certificate on Win
> ::> > > NT/2K,
> ::> > > > that is shared by all users of a workstation?
> ::> > >
> ::> > > 2K supports Kerberos, with certificate I believe
> ::> > >
> ::> > >
> ::______________________________________________________________________
> ::> > > OpenSSL Project
> ::http://www.openssl.org
> ::> > > User Support Mailing List
> ::[EMAIL PROTECTED]
> ::> > > Automated List Manager
> ::[EMAIL PROTECTED]
> ::> > >
> ::______________________________________________________________________
> ::> > > OpenSSL Project
> ::http://www.openssl.org
> ::> > > User Support Mailing List
> ::[EMAIL PROTECTED]
> ::> > > Automated List Manager
> ::[EMAIL PROTECTED]
> ::> > >
> ::> > >
> ::> >
> ::> >
______________________________________________________________________
> ::> > OpenSSL Project
http://www.openssl.org
> ::> > User Support Mailing List
[EMAIL PROTECTED]
> ::> > Automated List Manager
[EMAIL PROTECTED]
> ::> >
______________________________________________________________________
> ::> > OpenSSL Project
http://www.openssl.org
> ::> > User Support Mailing List
[EMAIL PROTECTED]
> ::> > Automated List Manager
[EMAIL PROTECTED]
> ::>
> ::> ______________________________________________________________________
> ::> OpenSSL Project http://www.openssl.org
> ::> User Support Mailing List [EMAIL PROTECTED]
> ::> Automated List Manager [EMAIL PROTECTED]
> ::> ______________________________________________________________________
> ::> OpenSSL Project http://www.openssl.org
> ::> User Support Mailing List [EMAIL PROTECTED]
> ::> Automated List Manager [EMAIL PROTECTED]
> ::>
> ::
> ::______________________________________________________________________
> ::OpenSSL Project http://www.openssl.org
> ::User Support Mailing List [EMAIL PROTECTED]
> ::Automated List Manager [EMAIL PROTECTED]
> ::
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
