Alan Altmark wrote: > RSA SecurID is normally integrated into the network access controls. That > is, authentication and host access authorization decisions are made at the > [VPN] network boundary (a la firewall), not on each host. > > That said, I have heard other requests for two-part authentication, > typically requiring X.509 user certificates for SSL/TLS, plus a > userid/password at the target service.
the technology is asymmetric key cryptography, i.e. what one key encodes, the other key decodes (as opposed to symmetric key cryptography which uses the same key for both encoding & decoding). a business process is public key ... where one key is designated as public and made readily available, the other key is designated as private, kept confidential and never disclosed. a business process is digital signature ... where the hash of a document/message is calculated, and a private key encodes the hash. the sender transmits the document/message along with the digital signature. the recipient recalculates the hash on the document/message, decodes the digital signature with the appropriate public key and compares the two hashes. if they are the same, then the recipient can assume: 1) the message/document hasn't been modified since digital signature was calculated 2) "something you have" authentication, aka the sender has access to and use of the corresponding private key. there was a business process developed called PKI and digital certificates ... to handle the situation corresponding to letters of credit/introduction from the sailing ship days for first-time communication between strangers. in the early 90s, x.509 identity certificates were formulated and proposals that x.509 identity certificates should be attached to every digital signature .... in order to turn EVERY (even the most light weight) authentication operation into heavy weight identification operations. Note that user certificates aren't needed for SSL/TLS. Server certificates are used for SSL/TLS ... as part of key exchange for encrypted communication (separate from authentication) as a countermeausre to evesdropping and snooping (i.e. harvesting user confidential information like passwords). misc. collected posts on ssl server certificates http://www.garlic.com/~lynn/subpubkey.html#sslcert one of the issues from the early 90s with x.509 identity certificates was that PKI operations didn't necessarily know all possible identification information that recipients (relying partys) might be interested in ... so there was some directly to grossly overload the certificates with enormous amounts of personal information. Going into the mid-90s, some institutions were starting to realize that x.509 identity certificates, grossly overloaded with personal information represented significant privacy and liability issues. As a result, you saw some effort creating relying-party-only certificates http://www.garlic.com/~lynn/subpubkey.html#rpo which contained little more than some sort of account number or other repository lookup/index and a public key. However, it is trivial to demonstrate that such relying-party-only certificates are redundant and superfluous. In some of these scenarios, the repository lookup/index is a "userid". In the simple case for entities with existing relationships, it is possible to upgrade password-based systems with public keys and digital signature authentication; basically the public key is registered in lieu of a password .... and the digital signature is transmitted in lieu of transmitting the password. No digital certificate is required as part of first-time communication between total strangers. misc. collected postings on simple digital signature authentication http://www.garlic.com/~lynn/subpubkey.html#certless one of the prevailing authentication mechanisms on the internet is radius .... originally a userid/password based implementation. However, there have been a number of (certificateless) public key enhancments for RADIUS implementations http://www.garlic.com/~lynn/subpubkey.html#radius another common authentication infrastructure that was originally userid/password is kerberos. the original pk-init draft for upgrading kerberos passwords to digital signature didn't even mention certificates http://www.garlic.com/~lynn/subpubkey.html#kerberos one of the possibilities for upgrading to straight public key and digital signature .... is that a server-side digital signature authentication infrastructure can be used regardless of the integrity of the user-side operation. basically the digital signature operations are "something you have" authentication. however, there can be a wide variation in the integrity of that "something you have". The lowest integrity is a software container that contains the private key. the sender has possession of the software container. there is a big integrity difference between have a private key in a straight software container and having it contained in some form of hardware token. the software container may be encrypted by default. for the owner to perform a digital signature, a decryption key must be supplied. this effectively now is two-factor authentication (the encrypted software container for the private key is "something you have" and the decryption key is "something you know") .... however, it wouldn't normally be considered extremely robust or high integrity two-factor authentication. for higher integrity two-factor authentication, the server-side might want to know that the private key is contained in a certified hardware token, possibly was generated inside the token and has never been outside the token. in any case, simply registering public keys in lieu of passwords has advantage over password mechanism since the public key can be used to verify the digital signature but can't be used to create a digital signature i.e. a password is used for both verification and origination ... which leads to impersonation vulnerability and the requirement that passwords be kept secret, be impossible to guess and memorize, have to be change frequently, and a unique password is required for each security domain. however, because of the wide-variety of possible private key environments, infrastructures that register public keys .... should also register the characteristics and integrity level of the associated private key environment (software, hardware, encrypted, single-factor, multiple factors, integrity level of the hardware, etc). this then leads to the "security proportional to risk" theme ... where a common digital signature environment can support a wide-variety of integrity levels ... and different permission levels be associated with different levels of private key integrity. misc. recent postings on possibly confusing authentication and identification http://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication http://www.garlic.com/~lynn/aadsm20.htm#5 the limits of crypto and authentication http://www.garlic.com/~lynn/aadsm20.htm#8 UK EU presidency aims for Europe-wide biometric ID card http://www.garlic.com/~lynn/aadsm20.htm#11 the limits of crypto and authentication http://www.garlic.com/~lynn/aadsm20.htm#14 the limits of crypto and authentication http://www.garlic.com/~lynn/aadsm20.htm#22 ID "theft" -- so what? http://www.garlic.com/~lynn/aadsm20.htm#31 The summer of PKI love http://www.garlic.com/~lynn/aadsm20.htm#32 How many wrongs do you need to make a right? http://www.garlic.com/~lynn/aadsm20.htm#42 Another entry in the internet security hall of shame http://www.garlic.com/~lynn/aadsm20.htm#43 Another entry in the internet security hall of shame http://www.garlic.com/~lynn/aadsm20.htm#44 Another entry in the internet security hall of shame http://www.garlic.com/~lynn/aadsm21.htm#2 Another entry in the internet security hall of shame http://www.garlic.com/~lynn/aadsm21.htm#12 Payment Tokens http://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the security challenges http://www.garlic.com/~lynn/aadsm21.htm#16 PKI too confusing to prevent phishing, part 28 http://www.garlic.com/~lynn/aadsm21.htm#17 continuity of identity http://www.garlic.com/~lynn/aadsm21.htm#19 mixing authentication and identification? http://www.garlic.com/~lynn/2005o.html#6 X509 digital certificate for offline solution http://www.garlic.com/~lynn/2005o.html#41 Certificate Authority of a secured P2P network http://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally be forced to sign a document etc - Tax Declaration etc etc etc http://www.garlic.com/~lynn/2005p.html#24 Hi-tech no panacea for ID theft woes http://www.garlic.com/~lynn/2005p.html#32 PKI Certificate question http://www.garlic.com/~lynn/2005q.html#13 IPSEC with non-domain Server http://www.garlic.com/~lynn/2005q.html#23 Logon with Digital Siganture (PKI/OCES - or what else they're called) http://www.garlic.com/~lynn/2005r.html#54 NEW USA FFIES Guidance http://www.garlic.com/~lynn/2005s.html#10 NEW USA FFIES Guidance http://www.garlic.com/~lynn/2005s.html#24 What ever happened to Tandem and NonStop OS ? http://www.garlic.com/~lynn/2005s.html#42 feasibility of certificate based login (PKI) w/o real smart card http://www.garlic.com/~lynn/2005s.html#43 P2P Authentication http://www.garlic.com/~lynn/2005s.html#52 TTP and KCM http://www.garlic.com/~lynn/2005t.html#0 TTP and KCM http://www.garlic.com/~lynn/2005t.html#6 phishing web sites using self-signed certs http://www.garlic.com/~lynn/2005t.html#9 phishing web sites using self-signed certs http://www.garlic.com/~lynn/2005t.html#22 What ever happened to Tandem and NonStop OS ?
