Hi all,
I have a question related to the piggybacking in EAP and was wondering if I
could get your guidance here:
I was working on a demo to demonstrate my customized protocol.
I was hoping to use the EAP method as phase 1 to build a secured channel using
TLS handshake (like EAP-TTLS) and then implement my own protocol as the phase 2
method.
I have checked some RFCs and noticed that both EAP-TEAP and EAP-TTLS seem to be
good choices here.
As to EAP-TEAP, it uses a TLS handshake to establish a secured tunnel and in
phase 2, it has EAP-Payload to allow you to encapsulate your protocol.
The problem is, it seems EAP-TEAP hasn't been widely supported yet, at least
not in HostApd.
As to EAP-TTLS, in RFC 5281 Section 7.4, it says
Such "piggybacking" occurs when the party that completes the
handshake also has AVPs to send. For example, when negotiating a
resumed TLS session, the TTLS server sends its ChangeCipherSpec and
Finished messages first, then the client sends its own
ChangeCipherSpec and Finished messages to conclude the handshake. If
the client has authentication or other AVPs to send to the TTLS
server, it MUST tunnel those AVPs within the same EAP-TTLS packet
immediately following its Finished message. If the client fails to
do this, the TTLS server will incorrectly assume that the client has
no AVPs to send, and the outcome of the negotiation could be
affected.
And I checked AVP lists, there is an "EAP" AVP available and but it seems to be
designed for AAA and needs to be always used with RADIUS
access-request/access-challenge (is that okay if I do not allow the server to
forwards the message in Radius access-request?).
Upon receipt of the tunneled EAP-Response/Identity, the TTLS server
forwards it to the AAA/H in a RADIUS Access-Request.
So my question is, besides EAP-TTLS, is there an EAP protocol that is widely
supported and can be used for piggybacking a customized protocol?
Thanks,.
Yuan
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu