Joseph Salowey (jsalowey) wrote: > There are other ways in which EAP has proposed authorization > enhancements. Other proposals have dealt with requesting authorizations > for or providing authorization data to services other than the one that > is performing the authentication. In addition proposals have discussed > authorization after the initial authentication to the service.
I think part of the concern here is that authorization has traditionally involved the PDP telling the PEP how the user should be treated. The proposals on the table for EAP do not communicate authorization information over EAP to the PEP. As such, they do not fit well into the traditional model. > I think carrying channel bindings within EAP is useful and necessary. I > believe it is also reasonable to carry other exchanges to establish data > for authorization. ... of who, to what? This could be made clearer in the document. > However, I think there are some limitations. For > example carrying large amounts of data is probably not a good thing. I > also think we have to be careful to not leave end stations with the only > means to communicate is through EAP. I don't think we should be > applying patches or browsing the web through EAP (I don't think anyone > is proposing this, but I'm not certain). I can propose EAP-IP: carrying IP packets in EAP. It's crazy, but possible. The main limitation on bulk data transfer is that most EAP to RADIUS gateways (AP's, etc.) will terminate an EAP session after ~50 packets. > When we get into the realm of using EAP for establishing authorization > data for other services, requesting authorization or invoking > authorization at times other than authentication I think there is a much > bigger gray area. ERP is leveraging EAP to obtain authentication and authorization at later points in time. This seems to be acceptable. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
