[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: shared secret vulnerability
See inline. (My comments marked [pf] ).
--- from Randy Chou ---
Thanks Paul for your draft and discussing with me on Monday. We can
further detail during Thursday's meeting, but here are some comments
- The draft-funk-radiusext-shared-secret-amp-00.txt doc provides a
way for people to still remember short passwords while providing
entropy. It would be good IMO to categorize the environments this
adequate security and the environments that it doesn't.
[pf] I agree. I think intra-domain vs. inter-domain might be a way to
Also, the ability to segregate administrative traffic from user traffic
- As I pointed in a previous email, this still wouldn't protect cases
the shared secret is somehow exposed. Perhaps we can document this
in the radius_vuln_00.txt draft as comments so far have been focusing
short shared secrets which was only one aspect of what was
Consumers have been educated for many years to understand that exposure
the private key (assuming RSA) of a certificate is the only way to
packets through sniffing during TLS handshakes. So certs are
carefully and access to it is very limited. However, in a wifi
w/ 802.1x, exposure of a previous Radius shared secret can also allow
attacker to decrypt wireless packets. So from an encryption point of
losing the current or any previously used Radius shared secret can be
fatal as losing the server cert. I don't think many consumers
that correlation and many would be shocked if they knew. The
security-conscious consumers use a combination of DH w/ RSA or ephemeral
so even losing the server cert doesn't allow for data decryption.
that data decryption is still achievable only through the loss of the
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
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.
available in most generic OSes where Radius servers are run and on many
devices. As to ease of deployment, I think this needs to be
having to rotate RADIUS shared keys routinely on potentially hundreds of
devices without duplicate usage, and making sure previous keys are
[pf] If it's not hard to use, why isn't it used more? Maintaining a PKI
administratively challenging. Yes, OSes have built in support, but NASes
may run on platforms where IPsec is not readily available. I doubt also
diligent shared secret rotation is all that common.
- Would like to hear security analysis of other uses of Radius
802.1x/wireless if anyone else has something to share.
----- Original Message -----
From: "Paul Funk" <email@example.com>
Cc: <firstname.lastname@example.org>; <email@example.com>;
"Bernard Aboba" <firstname.lastname@example.org>
Sent: Monday, August 02, 2004 10:11 AM
Subject: shared secret vulnerability
> To further the discussion of shared secret vulnerability
> up in radius_vuln_00.txt, here is a proposal for using PKCS-5
> to create shared secrets with enhanced resistance to
> The idea is that you take an ordinary secret, hash it many
> and get a resulting "amplified" shared secret that
> difficulty of attack by the number of times it has been hashed.
> draft suggests 0x100000 (~ one million) iterations, adding 2 ^
> bits of effective entropy to the secret.
> The draft can be found at:
> A demo of shared secret amplification can be found at:
> 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
> 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 Funk
> Funk Software, Inc.
> 617 497-6339
Funk Software, Inc.