A proposal for addressing this would be to state explicitly that solutions are only required to address hop-by-hop security. If more explanation is required, one or more of the following points might be included:
a. RADIUS currently does not support the Redirect facilities of Diameter, which allows a NAS to directly talk to a Diameter server assuming that appropriate credentials are available.
b. End-to-end protection requires that the NAS and RADIUS server can authenticate directly. Where pre-shared keys are used for authentication, this creates a scaling problem. Where certificates are available *and* re-direct (or automatic discovery) is available, the NAS can talk directly to the RADIUS server. However, this is an ongoing area of research/experimentation, which is not yet mature enough for standardization.
From: bernard_aboba@hotmail.com
To: radiusext@ops.ietf.org
Subject: Crypto-agility requirements: Hop-by-hop vs. end-to-end (from Issue 303)
Date: Sun, 28 Jun 2009 14:01:41 -0700
Hop-by-hop/end-to-end:
The document currently considers only "hop-by-hop" security
mechanisms, not any "end-to-end" protection (across proxies). I think
this is OK and perfectly reasonable -- but the document should say this,
and explain what this means for interpreting RFC 4962
Much of RFC 4962 is open to multiple interpretations, and some parts
of it can be read as requiring more than hop-by-hop security. IMHO
exactly the same parts can also be read as saying hop-by-hop can be
sufficient (when done properly), and I think this document should
explicitly say it's interpreting 4962 the latter way. (And once the
document has this explanation, you might want to run it by some other
ADs, too -- e.g. Tim and Russ)
|