Re: shared secret vulnerability

[Paul Funk <paul@funk.com>]

Randy,

See inline. (My comments marked [pf] ).

Paul

--- from Randy Chou ---

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.

[pf] I agree. I think intra-domain vs. inter-domain might be a way to
slice this. 
Also, the ability to segregate administrative traffic from user traffic
is 
important.

- 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.

[pf] I agree that people should understand the implications of their
security choices. But since they are entering shared secrets into 
security servers, you'd think people would understand that it must 
be important to the security of their operations.

[pf] Yes, DH will provide perfect forward secrecy, though I'm not sure
how many people attempt to configure that vs. use whatever the default
cipher suite happens to be. 

[pf] Whether you are protecting a private key or a shared secret, you
need 
to secure the equipment that uses it. I'm not sure that a shared secret
on a server is any less secure than a private key. Also, you have to
worry about your backup tapes!

- 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.

[pf] If it's not hard to use, why isn't it used more? Maintaining a PKI
is 
administratively challenging. Yes, OSes have built in support, but NASes
may run on platforms where IPsec is not readily available. I doubt also
that 
diligent shared secret rotation is all that common. 

- 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
>
>

Paul Funk
Funk Software, Inc.
617 497-6339
paul@funk.com