We have not yet specified how CB will work in TTLS. At the last IETF
meeting we discussed defining a new AVP for TTLS as a container for
diameter AVPs.
I have not yet talked to the TTLS authors to get that assigned.
The intent is that at some point in the exchange, the peer will send
this TTLS AVP containing diameter encoded channel binding data to the
server; the server will then respond with an an AVP indicating which if
any channel binding values it considered and the channel binding result.
It's possible that channel binding failure may trigger EAP failure or
that this will be left to the peer to decide.
So, for TTLS:
We need to get AVP values assigned and decide where in the protocol the
peer->server and server->peer messages go.
In generality, we need to explicitly say (presumably in
draft-ietf-emu-chbind)
1) What happens with the server to peer message for channel binding
failure
2) Explicit details of what goes in those messages.
Much of this can be inferred from the aaapay draft. One explicit
difference with that draft is that discussions at the last IETF
suggested that rather than using TTLS's existing mechanism to send
diameter AVPs directly, even for TTLS we're going to allocate an AVP
that explicitly means "this is channel binding data."
--Sam
|