Sam Hartman wrote:
>  After talking to
> TTLS folks we came to consensus that assigning a DIAMETER attribute type
> would be the most correct TTLS thing to do.  It turns out that at least
> for FreeRadius this is a bad idea; other RADIUS servers may well behave
> similarly.

  The limitation is there because the server packs attributes into an
"int".  Both the attribute number and vendor ID are packed into the
"int" for versions up to 2.x.  This means having a 32-bit Diameter
attribute is hard.  The high bits make the rest of the server think that
the attribute is a VSA.

  Many RADIUS implementations do the same.

  It's a bit better in 3.0.  The Vendor ID and attribute are placed into
separate int's.  So it *should* be possible.

> The issue is that packets containing DIAMETER attributes that
> cannot be mapped to RADIUS attributes cause the authentication to fail.
> So, we need a TTLS-specific RADIUS attribute to carry the channel
> binding information in the TLS tunnel.  While the IETF might think it
> funny if we requested such an attribute, we'd be unlikely to succeed.
> So, we're probably going to have to use a VSA for that purpose.  Alan
> suggested this at the beginning; apologies for trying to find a more
> architecturally correct solution and wasting time.

  If you're adding this to 3.0 (and I suggest that's the best way), then
using a Diameter attribute should be possible.  The only change to
FreeRADIUS is some minor tweaks to allow it to work.

  I've done similar tweaks for WiMAX, so it shouldn't be hard.

> The good news is that we're through a good chunk of the authentication
> server and peer implementation of EAP channel bindings and while we're
> running into rough edges, nothing that seems to break the conceptual
> model.

  That's good to hear.

  Alan DeKok.