Re: [Emu] Consensus call on EAP Tunneled method
Q1:Yes Q2: I support using EAP-Team since it more fits for requrements defined in I-D.ietf-emu-eaptunnel-req. - Original Message - From: "Alan DeKok" To: Sent: Wednesday, March 30, 2011 2:29 PM Subject: [Emu] Consensus call on EAP Tunneled method > For people who didn't attend the EMU meeting at IETF, please answer > the following consensus call: > > Question 1: Are you ready to make a decision on the EAP tunneled method? > > Please indicate Yes or No. > > Question 2: If the answer to Question 1 is "Yes", please indicate > support for one of the two proposed methods: > > FASTv2 > or > EAP-Team > > Alan DeKok. > EMU Co-Chair > ___ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Impersonation and Lying NAS problem: two distinct issues (with different solutions)
It seems to me, the consistency between EAP peer and EAP Server can be caused by the Lying NAS Even this NAS is not malicious authenticator who impersonates another authenticator, this NAS should be a stupid NAS or malfunctional NAS who make a mistake for some reason. Because this NAS distributes inconsistent data to the peer and server respectively. >From this aspect, the lying NAS can be understoond as ill NAS. am I right? On the other hand, as described in the section 5.3.3, " it is possible for a first-hop AAA proxy to detect a AAA client attempting to impersonate another authenticator. " Based on this, impersonation issue seems to overlap with channel binding or lying NAS issue. Regards! -Qin - Original Message - From: "Bernard Aboba" To: Sent: Tuesday, August 18, 2009 1:42 PM Subject: [Emu] Impersonation and Lying NAS problem: two distinct issues (with different solutions) > Dan Harkins said: > > "When there are 3 parties involved in this 2 party protocol it is > justified by saying that the EAP server trusts the NAS so there is no > security issue when MSK is disclosed to it. But what NAS identity does > the EAP server trust? The peer and EAP server derive a shared key and > for the key to be disclosed to another entity the peer and EAP server > must have a consistent view of the identity of that entity. If they cannot > arrive at a consistent view of all identities then the protocol deriving > the key fails. That is not an authorization issue, it's an authentication > issue." > > RFC 5247 Section 5.3.2 describes problems that can result from a NAS > impersonating another NAS. Section 5.3.3 describes the Channel > Binding problem, which is logically distinct. > > As noted in Section 5.3.2, it is not possible for a AAA server more > than one hop from the NAS to verify the NAS Identity. This verification > must be handled at the first hop proxy. > > Given this, it will typically be outside the scope of a Channel Binding > Implementation to address the impersonation issue. > > ___ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] EAP and authorization
> 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. [Qin]: So the data resulting from the authentication not only can be used in the authentication, but also can be used in authorization. I wonder what it is called as, authentication data or authorization data? On the other hand, the data resulting from authorization also can be used in the second authentication. e.g., PEAP uses TLS to create an encrypted tunnel from the authentication server to the supplicant after verifying the identity of the authentication server. Once the encrypted tunnel is established, a second EAP authorization process occurs inside the tunnel to extend the TLS connection. Any implemented EAP authorization type (tokens, passwords, certificates, etc.) can be used as the client is authenticated in the second EAP authentication process running inside the TLS connection. As regarding these data from authorization, what is it called as, authentication data or authorization data? >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. > ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] EAP and authorization
Hi, Alan: - Original Message - From: "Alan DeKok" To: "Joseph Salowey (jsalowey)" Cc: Sent: Friday, August 14, 2009 2:16 PM 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. > >> 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. [Qin] Why not carry EAP over Http, in this way, you can browse Web through EAP. Actually there are still other way for Web Authentication, e.g., SIP. >> 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. [Qin]: I agree that the authorization is well integrated into ERP authentication. However these authorization data (i.e., authorization indication described in section 5.3.4 of ERP) is only limited to Called-Station-Id ,Calling-Station-Id , NAS-Identifier, NAS-IP-address, NAS-IPv6-address which is listed in RFC3748. What's more, ERP has nothing to do with EAP method. > Alan DeKok. > ___ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
