Sam Hartman wrote:
> 1) It's difficult to use KNP for keying other AAA protocols. The details
> have become rather RADIUS specific in Alan's proposal. While you could
> use something similar for Diameter you'd end up redoing a lot of the
> spec and implementation work.
The Diameter people use security? Odd... most of what I've heard is
that it's usually bare TCP with nothing more than source IP filtering.
> 2) It seems to more require your KNP implementation be heavily tied into
> your RADIUS implemenetation.
How many other federated authentication deployments are there?
> 3) You seem to have modified the RADIUS state machine somewhat and I'm
> concerned that it's going to be harder to perform security analysis of
> this than a separate protocol.
I don't see how. (i.e. RADIUS has a state machine?)
> 4) You probably need an integrity protected channel for parts of
> KNP. EAP doesn't give you an integrity-protected channel with the right
> parties. Josh's approach of using EAP to key TLS does get you this, but
> there are (mostly political and implementation) costs associated with
Why? EAP already runs over insecure Wifi / wired links. The entire
design goal of EAP is to run over untrusted channels. The EAP method
used for bootstrapping needs channel bindings and integrity protection,
but that's already available.
> 5) I don't actually see advantages to tieing this to RADIUS. We're
> talking about something that runs on relatively high-end
> servers. Supporting multiple protocols does not seem to be a problem.
For me, it's fragility. My proposal involves essentially re-using the
RadSec infrastructure to bootstrap new RadSec connections. The only
interface between the KNP and new RadSec connections is that they need
to share keying information.
I could take a RadSec client *today*, and with a little bit of shell
scripting, use EAP, and glue the MSK from the RadSec client to a new
The alternative is a protocol soup of HTTP, GSS, etc.
> 7) Politically I don't think this approach can be standardized in the
> time available. It would have to be done in RADEXT. KNP makes a lot of
> ABFAB specific assumptions; doing it in a context general enough to work
> for RADEXT seems problematic to me.
Possibly. RADEXT has a history of taking years for any decision.
> This approach does have one significant advantage I can see: it removes
> an asymmetric relationship. In our protocol, depending on whether the
> next party to talk to is a RADSEC entity or a KNP entity, the kind of
> keys you need end up being different. Alan's approach removes that.