Re: shared secret vulnerability

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

Comments inline before I go to sleep...[rc]...

Regards,

--
Randy


----- Original Message ----- 
From: Paul Funk
To: radiusext@ops.ietf.org ; rchou@arubanetworks.com
Cc: merv@arubanetworks.com ; jwright@sans.org ; Bernard Aboba
Sent: Thursday, August 05, 2004 12:04 AM
Subject: Re: shared secret vulnerability


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.

[rc] I like that.  Especially now that there are Radius services on the
internet being provided for 802.1x.  Scary eh?


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

[rc] Note that the shared secrets also go into generic NAS devices that
normally don't provide security features.

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

[rc] Agreed, and this isn't just a Radius problem (SNMP, telnet,...etc).  I
think a shared secret versus cert difference is that the shared secret also
resides on many NAS devices which makes it much more difficult to protect.

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

[rc]  IPSEC is deployed widely for end-users.  My theory as to why it's not
commonly used for Radius (there are some that do use it) is because of lack
of understanding (amongst consumers) of the seriousness of the problem and
because it's only a recommendation in the RFC as opposed to an absolute
requirement.  Hence the draft we wrote.

- 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


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