Re: E2E and crypto-agility

[Alan DeKok <aland@nitros9.org>]

Glen Zorn wrote:
> It's hard to see how this solves any known problem.  We already know how te
> secure the key on the wire; the only problem is with evil proxies.

  Um... if you don't trust the proxies, why are you letting them control
access to your network?

  RADIUS authentication routing is *not* IPv4 packet routing.  There are
commercial agreements in place for RADIUS traffic between any two
networks.  This isn't true for IPv4.

>  Since in
> the last step the end-user transmits K'' to the NAS (necessarily unencrypted
> since the peer & NAS do not yet share any keying material)

  The NAS can prove to the peer that it knows the encrypted key.  The
peer can then send the NAS the decryption key, or any other key
derivation function.

> you have
> basically divulged your key-encrypting key to the world, which of course
> includes any RADIUS proxies that were in the forwarding path.  So what does
> this help?

  Giving a key to the NAS is equivalent to giving it to the local AAA
server, because they are run by the same administrative entity.  So
*any* proposal that gives keying material to the NAS is vulnerable to
this attack.

  If the desire is to protect against third-party proxies, such as
roaming or interconnect providers, see my first set of comments.  In
addition, the local NAS (and AAA server) can choose to share that keying
material with anyone else in the world, including RADIUS proxies.  This
is true today.

  The MPPE keys used for 802.1x keying today are shared in the clear
with all RADIUS proxies.  Is there a *real-world* problem we're trying
to solve here, or a theoretical exercise that is made moot by real-world
business realities?

  Alan DeKok.

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