There have been a lot of proposals about EAP and authorization in the past. At its very basis EAP performs authentication at the time of service access and the data resulting from the authentication can then be used for authorization and accounting purposes. Some of the proposals attempt to enhance this in various ways.
One way is to carry additional data for use in the authorization process. EAP channel bindings are perhaps the simplest form of authorization data proposed for EAP. The authorization data is directly related to the service which is performing the authentication, at the time of authentication and the exchange is relatively simple; data sent from client and result response from server. This exchange helps to ensure that an authenticator isn't trying to provide services that it is not authorized to. I don't see much purpose in channel bindings if they are not used for authorization or accounting for later forensic analysis of authorization after the event. There are other types of data that may be collected for authorization. One example is the validation of the "security posture" of the peer in which information about the peers compliance with a particular policy is collected. This example may require the exchange of more data and require more complex exchanges than channel bindings. This process may even involve authentication. 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 carrying channel bindings within EAP is useful and necessary. I believe it is also reasonable to carry other exchanges to establish data for authorization. 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). This means that a some point other communication channels have to be established to perform these functions. 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. Joe > -----Original Message----- > From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On > Behalf Of Alper Yegin > Sent: Friday, August 07, 2009 6:31 AM > To: emu@ietf.org > Subject: [Emu] EAP and authorization > > This issue came up during the last IETF meeting when the WG > discussed channel binding. > > > > Pasi said the discussion was within the scope of EMU WG charter. > > > > - A document that defines EAP channel bindings and provides > guidance for establishing EAP channel bindings within EAP methods. > > > > > > - A mechanism to support extensible communication within a > TLS protected tunnel. > > > > > > I'm not against this. But let's face it, this is venturing > into dealing with authorization parameters with EAP (EAP > layer? EAP method layer? Etc.) I'm not against that either. > In fact, I know there are a lot of people who'd be happy to > see that happen. > > > > So, my question is, is this what we are doing: Enabling EAP > to exchange authorization parameters among the EAP peer - > authenticator - authentication server? If not, I hope someone > can explain how this is different than what it takes to solve > channel binding problem. > > > > Thanks. > > > > Alper > > > > > > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
