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

Tue Jun 30 22:41:17 EDT 2009

Wow, Thanks Bryan !
Sorry for the ambiguity.
Based on my limited knowledge in this area (mostly being an app developer), 
per the direction of our boss were told to explore RSA two factor remote 
access solutions.
Hence, the "RSA" solutions we exploring were those offered by the RSA EMC 
subsidiary.
We are considering the (SecureID) token fobs (non USB) and either the 
server or the appliance back end solution.
Currently we use tokenless Sonicwall VPN.
We're mostly a MS development shop so we would integrate into AD.
We'd like to do this ourselves, if possible. My colleague was exploring the 
actual pricing /procurement and it seemed like you are directed to the VAR 
channel, where you buy the HW, setup services and maintenance agreement.
Ben

At 06:53 PM 06/28/2009 -0700, Bryan J. Smith wrote:

>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