Return-Path: <IME-Version: 1.>
Received: (from root@localhost) by example.com (8.11.6/8.11.6/SuSE Linux 0.5) id h4CMt1U02501 for root; Mon, 12 May 2003 17:55:01 -0500
Date: Wed, 17 Feb 2010 22:45:21 -0000
MIME-Version: 1.0
Message-Id: <200305122255.h4CMt1U02501@example.com>
To: abfab@ietf.org
Content-Type: text/plain; charset="us-ascii"
Josh previously wrote:
> Bad news. As I suspected, it is a requirement that the=20
> call-back used to
> the resolve the artifact is authenticated at the transport layer.
> Scott's advice was to avoid artifact resolution "at all costs". I see
> two possible options:
>=20
> 1. Ignore the RADIUS spec's MTU requirement...
>
> 2. TAS and TAC derive a new key for the artifact call-back from the
> established AAA context...

We discussed this issue at the Vienna meeting today.

Stefan Winter was clear that he thought that using RADSEC was a bad
idea, and that it would be cleaner to use another EAP lower layer for
transporting EAP between trust authorities. He believes that attempting
to manage the legacy RADIUS issues (primarily RADIUS MTU and attribute
size limitations) would result in major headaches.

We discussed various alternative strategies, including Diameter, XMPP
messaging, a lightweight XML schema over HTTP, or the use of WS-Security
binary tokens. Stefan is leaning towards XML over HTTP, but XMPP looks
more interesting to me. Could we model this by using XMPP and the EAP
GSS mechanism to establish the trust relationship between TAS and TAC,
and within this XMPP session transport EAP messages (plus SAML messages,
and derived EAP key and channel bindings) between C and TAC?

Unfortunately I don't enough about XMPP to understand whether it would
make a good EAP lower layer. I can't see why not in principle, but I
suspect there are aesthetic issues at the very least.

In addition, from an implementation perspective, ease of integration
with FreeRADIUS is probably the most critical consideration (for access
to the EAP machinery), but adding XMPP functionality to FreeRADIUS does
not seem a natural extension. I don't believe we want to gateway between
XMPP and RADIUS, as we introduce the issues of using RADIUS.

josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024=20
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG