Bernard_Aboba@hotmail.com wrote:
>> What is "end to end" ?
>
> I think it means something like "protection of RADIUS attributes from
> disclosure to parties other than the NAS and home server".
OK. I just wanted to be sure.
> In the AAA WG there were a number of mechanisms investigated by
> which a NAS and home server could derive a key that could be
> used to protect attributes from disclosure to proxies. These methods
> included Kerberos and CMS. For example, see:
> http://www.watersprings.org/pub/id/draft-kaushik-radius-sec-ext-06.txt
i.e. The NAS somehow knows a realm, knows how to talk to a server for
that realm, and can obtain a secret key for that realm.
> So I think the question is not "can it be done?" but rather "how does
> this relate to RADIUS crypto-agility?" and
> "should solving this problem be a requirement?"
I would say that it is a problem we should try to solve. I'm not sure
how much it affects crypto-agility.
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.
For EAP-TLS based methods, the TLS master session key can be used to
derive keying material. We would need to define one new RADIUS
attribute to transport the keying material E, and update EAPoL to
transport K''. This capability could be negotiated between the NAS and
supplicant, and advertised to the home RADIUS server by the supplicant,
inside of the TLS tunnel.
So far as crypto-agility goes, this method needs to be extensible to
multiple key sizes, encryption methods, authentication hashes, etc. But
it's independent of transport proposals such as DTLS or TLS.
(insert standard disclaimer here: this proposal has not been vetted by
a crypto expert)
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/>