Re: [ Comments on automated key management and crypto agility

[Alan DeKok <aland@nitros9.org>]

Bernard Aboba wrote:
> However, this is logically separate from the need to provide end-to-end
> protection for key transport.

  What is "end to end" ?

  Not to be dumb, but there are a number of parties involved:

  supplicant (or end user software)
  NAS (or AP)
  local RADIUS server
  intermediate proxies (0 or more)
  home RADIUS server (may be the same as the local RADIUS server)

  Which ends are we talking about?  The EAP-TLS methods allow the
supplicant and home server to agree on a key.  So any "end to end"
problem would appear to be getting keying material from the supplicant
OR home server to the NAS, without exposing that material to any local
server, or proxy server.

> So far, the need to solve the end-to-end key transport problem has not
> been part of RADIUS
> crypto-agility requirements.  Should it be?

  I don't see how we could do NAS to home server key transport in
RADIUS.  So the answer is (I think) "No".  Any end-to-end key transport
should involve EAP-TLS methods *and* RADIUS, I think.  Just doing it in
one or the other wouldn't work.

  If we tried to do it in RADIUS, we would end up with something that
looked nothing like RADIUS.

> With Diameter, it was clear that the IESG expected a solution to both
> problems -- ciphersuite
> negotiation (via TLS/IKE) as well as a mechanism for avoiding key
> disclosure to proxies
> (e.g. redirect).

  redirects have problems in practical deployments.  Intermediate nodes
often exist for commercial reasons, both for business relationships and
for application of intermediary policies.

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