RE: E2E and crypto-agility

["Glen Zorn" <glenzorn@comcast.net>]

...

  Back to my earlier question about "end to end", I think the only ends
that matter are the end user and home server.  The NAS is in contact
with both, and can leverage it's relationship with the end user to do
things that are normally impossible in RADIUS.   If we assume that the
end user and home RADIUS server can independently derive keying
material, then the server can supply keying material to the NAS, and the
end user can do the same.  The NAS can then derive keying material,
without it being exposed to anyone else.

  e.g. RADIUS, end-user: derive K', K''
       RADIUS -> NAS: E = ENC(K')         (using key K'')
       end-user -> NAS: K''

  If we assume that each RADIUS hop also encrypts E using the
Tunnel-Password method:

       T = tunnel_encrypt(per-hop-secret, E)

  Then we have the following properties:

  - no RADIUS proxy knows K' (they only know E)
  - The NAS can derive K' from E and K''
  - an attacker watching RADIUS only knows T
  - an attacker watching the end-user traffic only knows K''
  - an attacker watching *both* RADIUS and supplicant traffic knows
    T and K'', which is insufficient to derive K'
  - any intermediary RADIUS proxy that handles tunnel-password
    encryption can transport E.
[gwz] 
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.  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) 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?
[/gwz] 



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