Re: shared secret vulnerability

["Randy Chou" <rchou@arubanetworks.com>]

Thanks Paul for your draft and discussing with me on Monday.  We can go into
further detail during Thursday's meeting, but here are some comments to
think about:

- The draft-funk-radiusext-shared-secret-amp-00.txt doc provides a practical
way for people to still remember short passwords while providing good
entropy.  It would be good IMO to categorize the environments this provides
adequate security and the environments that it doesn't.

- As I pointed in a previous email, this still wouldn't protect cases where
the shared secret is somehow exposed.  Perhaps we can document this better
in the radius_vuln_00.txt draft as comments so far have been focusing on
short shared secrets which was only one aspect of what was documented.
Consumers have been educated for many years to understand that exposure to
the private key (assuming RSA) of a certificate is the only way to decrypt
packets through sniffing during TLS handshakes.  So certs are protected very
carefully and access to it is very limited. However, in a wifi environment
w/ 802.1x, exposure of a previous Radius shared secret can also allow an
attacker to decrypt wireless packets. So from an encryption point of view,
losing the current or any previously used Radius shared secret can be as
fatal as losing the server cert.  I don't think many consumers understand
that correlation and many would be shocked if they knew.  The more
security-conscious consumers use a combination of DH w/ RSA or ephemeral RSA
so even losing the server cert doesn't allow for data decryption.  The fact
that data decryption is still achievable only through the loss of the Radius
shared key makes Radius look very bad IMO.

- Would like to understand why you think IPSEC is so hard to use.  They're
available in most generic OSes where Radius servers are run and on many NAS
devices.  As to ease of deployment, I think this needs to be compared to
having to rotate RADIUS shared keys routinely on potentially hundreds of NAS
devices without duplicate usage, and making sure previous keys are never
exposed.

- Would like to hear security analysis of other uses of Radius besides
802.1x/wireless if anyone else has something to share.

Regards,

--
Randy


----- Original Message ----- 
From: "Paul Funk" <paul@funk.com>
To: <radiusext@ops.ietf.org>
Cc: <rchou@arubanetworks.com>; <merv@arubanetworks.com>; <jwright@sans.org>;
"Bernard Aboba" <aboba@internaut.com>
Sent: Monday, August 02, 2004 10:11 AM
Subject: shared secret vulnerability


> To further the discussion of shared secret vulnerability brought
> up in radius_vuln_00.txt, here is a proposal for using PKCS-5
> to create shared secrets with enhanced resistance to dictionary
> attack.
>
> The idea is that you take an ordinary secret, hash it many times,
> and get a resulting "amplified" shared secret that multiplies the
> difficulty of attack by the number of times it has been hashed. The
> draft suggests 0x100000 (~ one million) iterations, adding 2 ^ 20
> bits of effective entropy to the secret.
>
> The draft can be found at:
>
http://www.funk.com/documents/draft-funk-radiusext-shared-secret-amp-00.txt
>
> A demo of shared secret amplification can be found at:
> http://www.funk.com/passwordamplifier
>
> Here is the abstract:
>
>     This draft describes how a mechanism defined in [PKCS-5] can be used
>     to amplify the security of a RADIUS shared secret; namely, that a
>     precursor secret is hashed many times to produce an amplified shared
>     secret for use in RADIUS.
>
>     A dictionary attack against the resulting shared secret will be
>     infeasible due to its high entropy. A dictionary attack against the
>     precursor secret will require the attacker to apply the same hashing
>     process to each candidate precursor secret to derive a candidate
>     RADIUS shared secret, prior to applying it to the RADIUS packet.
>
>     This approach allows administrators to use the same types of secrets
>     that they are comfortable with as precursor secrets. The algorithm
>     to generate the amplified shared secret is deterministic, so the
>     precursor shared secret is all that needs to be remembered.
>
>     Unlike approaches that require changes to RADIUS servers and
>     clients, the amplification approach is compatible with all current
>     equipment. It is simply a means to generate a shared secret, which
>     then may be configured in the NAS or RADIUS server just as any
>     shared secret would be. For example, a simple utility can accept the
>     precursor secret, amplify it, and present it to the administrator,
>     who may copy and paste it into the configuration application of a
>     RADIUS server or NAS.
>
> Paul
>
>
> Paul Funk
> Funk Software, Inc.
> 617 497-6339
> paul@funk.com
>
>


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>