On Sun, 11 Mar 2001, bruce cartland wrote:
: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,
[edited]
I understand...a certain amount of trust is given to the connection as you
have a pre-existing relationship with that organization. The LIDs are
distrbuted by you to start with and you form them with info based on what
org they are to be used from so that is one more cross-check. That
correct? sounds good.
: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!!!
You might want to take a look at the IETF draft on impersonation
and delegation in TLS(SSL)...This allows you to have every entity as a CA
(and you thought you were just joking!). This ability mixed with the
original creds locked in an SC would mean that the original creds are used
even less...they just sign 12-hr session keys.
http://search.ietf.org/internet-drafts/draft-ietf-tls-delegation-00.txt
Later,
derek
:
:----- 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]
:
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
