[CALUG] seeking RSA advice -- RSA "SecurID" perhaps?

[Bryan J. Smith]

From: "benalgo at speakeasy.net" <benalgo at speakeasy.net>
> We're researching implementing RSA remote authentication.

"RSA remote authentication" is rather ambiguous.

Understand ...

- RSA is an acronym named after three people
  http://en.wikipedia.org/wiki/Ron_Rivest  
  http://en.wikipedia.org/wiki/Adi_Shamir  
  http://en.wikipedia.org/wiki/Leonard_Adleman  

- RSA is commonly known for their first cryptographic algorithm
  Patent:  http://www.google.com/patents?vid=4405829  
  The patent expired in 2003, but was made public domain in 2000

- RSA is the name of a corporation
  http://en.wikipedia.org/wiki/RSA_Security  

- RSA has produced several cryptographic algorithms
  (too many to list -- asymmetric/public key, symmetric, hash)

- RSA has many products implementing these algorithms
  http://www.rsa.com/node.aspx?id=1155  

> Does any one have any experience in this (vendor / solution
> recommendations / in house configuration) ?

I'm going to take a guess and assume you're referring to "SecurID":  
  http://en.wikipedia.org/wiki/RSA_SecurID  

By way of a hardware key synchronized with time, SecurID is a
multi-factor solution.  It makes it much more difficult to spoof
credentials.  There are software mechanisms for this as well.

All of these solutions utilize a pre-shared key/seed.  That way
the pre-shared key/seed is _never_ passed over the Internet.

E.g., in "skey" (a software approach), a pre-shared passphrase is
entered on the server.  The server then issues a challenge to the
client, something only that pre-shared passphrase can unlock.  That
sets up an encrpted tunnel -- much more security than without a
pre-shared passhrase -- which allows other credentials to pass far
more securely (e.g., the normal password or certificate/challenge).

Hence why it is called two-factor or multi-factor.

There are so many options, you can (and people have) literally wrote
books on this.  The main thing is that these designs involve pre-shared
information, so things are never sent/exposed over the Internet.  Any
information sent over the Internet is very time-limited, and useless
after a short period of time.  These are sometimes referred to (quite
distractingly) as "one-time passwords."

In the case of most hardware solutions, the seed/key is _never_ exposed
on the computer.  In the case of SecurID, it's an internally stored seed
on a timer.  In the case of smartcards, it takes an public key (asymmetric)
encrypted temporary key, and returns the temporary key (only the smartcard
can do it).

> It "seems" like the only way to score a (RSA) setup is to go
> through the VAR channel.
> (meaning you can't buy the appliance or server solution and
> tokens and set it up yourself)  Does anyone know if this true ?

If you implement RSA SecurID, then you will need to buy hardware
and the back-end.  The back-end on its own can interface via many
options ...

- RADIUS services (pass-thru from another back-end)
- PAM plug-in (e.g., NSS**/Kerberos** do _not_ use RSA natively)
- MS Active Directory plug-in (AD** does _not_ use RSA natively)
- Novell eDirectory plug-in (Novell** _does_ use RSA natively)
- Sun One plug-in (Sun One** _does_ use RSA natively) 
- several other options (mostly pass-thru)

> Conversely the primary incentive for considering this is
> compliance w/govn't contractor security requirements.
> So in that vein does anyone if that is true and a RSA solution
> is the only approved one ?


*NO*, it is not.  I assume the requirement is for a hardware-based
token, and not software (e.g., skey, among others).

Red Hat Directory Server** (RHDS) and its Certificate Server** supports
smartcards in use by our military personnel in Iraq.  Smartcards can
utilize a variety of options, DSS/DH instead of RSA, etc...

The RSA algorithm and the RSA SecurID approach is just _one_ option for
hardware implementation.

-- Bryan

P.S.  Red Hat has Solution Architects (SAs) that can help you with
your evaluation of options.  Please contact me off-list at this
address or, better yet, at my Red Hat address that starts with "bjs@").

**Deeper discussion:

Novell (original DAP implementation) and Sun (Michigan LDAP
implementation, actually licensed from Netscape iPlanet LDAP) have
native RSA support becauase they utilize RSA for their public key /
asymmetric algorithms, symmetric cipihers and crypto hashes.  So
RSA SecurID plugs well into them.

Microsoft (legacy NTUSER/SAM plus Michigan LDAP implementation) and
Netscape iPlanet (who hired the Michigan LDAP team) / Security Services
(NSS), utilize IETF-standard algorithms and, optional (standard
in ActiveDirectory and IPA), Kerberos (DES/AES, instead of RSA), NSS and
Certificate Services (X.509 with DSS/DH and others).  For these solutions,
pass-thru mechanisms and/or add-ons must be used.

The iPlanet Directory / Certificate Server (DS/CS) products are now
Red Hat products.  They have been GPL/MPL'd and are fully avaialble as
Port389.org (fka Fedora Directory Server), and off-shoots (e.g., IPA
which chucks IETF schema for NTUSER schema, requires Kerberos, etc...
so it "acts like" ActiveDirectory).

Again, SmartCards are also options, many of which use standard algorithms
such as DSS/DH asymmetric, DES/AES symmetric, MD5/SHA1/AES-hash hashes,
etc...


-- 
Bryan J Smith                 Professional, Technical Annoyance
b.j.smith at ieee.org      http://www.linkedin.com/in/bjsmith
--------------------------------------------------------
I don't have a "favorite Linux distro."  I use, develop
and support community efforts, often built around Linux.
Technology and solutions are my focus, not dragging in
assumptions, marketing and other concepts which dominate
non-community developed software, which I left long ago.




Much TIA,
Ben





_______________________________________________
CALUG mailing list
CALUG at unknownlamer.org
http://lists.unknownlamer.org/listinfo/calug