Josh Howlett wrote:
> We plan to push ahead with the Trust Router and Key Negotiation Protocol.
> The purpose of this meeting is to discuss requirements and reasonable
> design strategies, the work that has been completed to date and future
> plans.
I'll be in London then, but will be at another meeting, and won't be
able to attend.
Is there more background than the slides from IETF 80? I've also read
draft-howlett-radsec-knp-01. I'm not completely clear on what's going
on. The use of HTTP and GSS doesn't seem necessary...
My vision of how this could work would be the following. We keep the
Introducer, Client and Server.
1) Client starts RadSec with Introducer.
Security here is pre-provisioned, and out of bounds of this protocol.
PSK, certificates, secrets, etc.
2) The TLS portion of RadSec allows for the derivation of session keys.
These keys can be used to derive secondary keys for authentication.
3) The Client starts RadSec with Server.
This session is unencrypted, unauthenticated.
4) Client does EAP to over RadSec to Server, using credentials
derived from step (2). The credentials include the DNS domain
name (or realm) of the Introducer.
5) The Server forwards EAP to Introducer, using pre-existing RadSec
connection. The security of this connection is out of bounds
of this protocol.
6) If authenticated, Introducer derives EAP-MSK, and sends it to
Server. Client also derives EAP-MSK.
7) Client drops RadSec connection from (3), and starts a new one using
keys derived from the MSK in step (6).
8) Client sends traffic over new RadSec connection.
The nice thing is that this leaves everything in RADIUS. There's a
bit of magic required to derive the identities. There's a bit of magic
required to separate Client authentication from end-user authentication.
I think it's pretty similar to the approach in the draft.
Alan DeKok.
|