> -----Original Message----- > From: Alan DeKok [mailto:al...@deployingradius.com] > Sent: Thursday, August 13, 2009 11:16 PM > To: Joseph Salowey (jsalowey) > Cc: Alper Yegin; emu@ietf.org > Subject: Re: [Emu] EAP and authorization > > 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. > [Joe] In the traditional Model, peer entity authentication is performed and the identity information is communicated over EAP to the PDP. The PDP uses this information to make authorization decisions which are communicated to the PEP. I don't think the proposals of this type differ from this model except that the information that is established is not strictly identity information. The information collected may have different security properties than the authenticated data.
> > 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. > [Joe] I don't think a general discussion of authorization belongs in the channel bindings document. Channel bindings is much smaller scope than the general authorization problem. Is there something about channel bindings that is unclear 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. > [Joe] There are a great many things that are possible and even practiced, this does not make them wise. We have several good transport protocols for carrying bulk data. EAP is not one of them. > > 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. > [Joe] Yes, I agree there seems to be some precedence here, but the use cases may vary from the handover case. > Alan DeKok. > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
