Hi Joe, I don't see much wrong with EAP-GTC, and I may end up using it for legacy RADIUS support, But there are two arguments against using it.
1. The typical deployment of an IKE gateway is that there's a RADIUS or LDAP server somewhere in the internal network or even on another network in the case of a branch office gateway. EAP is usually forwarded to that server. If the forwarded payload is GTC, it's something malicious (perhaps on the internal network) might sniff it and get the password. 2. There is a threat scenario described in http://eprint.iacr.org/2002/163 . The idea is that a client that does EAP-GTC will do it both in a secure tunnel (such as in IKEv2) and outside of a secure tunnel (such as 802.1x). Someone sniffing the 802.1x will be able to acquire the password. This sounds simplistic to me, but more realistically, if IKEv2 (or even more so - TLS) is authenticated with a password, it may be tempting, as Dan pointed out, to uncheck the "verify server certificate" because "we're authenticating with a certificate". IOW, the user is actually authenticating to the RADIUS server, which tells the gateway that the user is authenticated. Since the gateway can't authenticate the user on its own, it makes sense that the client can't authenticate the gateway on its own. The RADIUS server sends the MSK to the gateway and the gateway sends a PoP to the client, and that is the proof the client has that the gateway is "authentic". But for this to work, you need an EAP method that (1) generates keys, and (2) mutually authenticates the client and server. These are required in the IKEv2 RFC. Tunneling a method like EAP-GTC gives you the keys and the mutual authentication but it requires that the client be able to verify the server certificate, and it requires that the tunneling go all the way to the server, rather than GTC going to the server, while the tunnel terminates at the gateway. It still takes a lot of round trips to get it to work, and a non-tunneled method like EAP-SRP or EAP-pwd would probably be better suited. Yoav On Apr 28, 2008, at 9:41 PM, Joseph Salowey (jsalowey) wrote: > Hi Yoav, > > You bring up an interesting point in discussing the need for EAP > password based authentication within other protected protocols. If > this > is targeted at working with legacy databases then I think it can be > accommodated under the current charter. An EAP protected tunnel is > required for some deployments, however perhaps the tunneled password > protocol can be designed to be used in other cases (IKEv2, TLS, > etc.) if > the group wants to take this direction. What do you see lacking in > something like EAP-GTC? > > Cheers, > > Joe > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >> Behalf Of Yoav Nir >> Sent: Monday, April 28, 2008 5:13 AM >> To: emu@ietf.org >> Subject: Re: [Emu] EMU charter revision >> >> Gene Chang said: >> >> >> >> Dan, >> I am not sure I am able to clearly understand the end >> result you seek. >> It seems there is a clear consensus for a tunneled >> method. Are you >> pushing for the addition of a tunneled method? >> >> Ok... I am easily baited. What would you like to see to >> achieve more >> than a snail race? I am assuming we both believe the >> term "snail race" >> is a pejorative. Thus I ask you, how do we do better? >> >> I clearly hear your comment that there have been a >> paucity of comments, >> if nothing else, simply to affirm we are on track. I >> agree with the >> proposed charter. I am open to a discussion to add a >> non-tunneled method >> if there is sufficient demand. A non-tunneled method >> does not seem to >> promise enough features for the use cases that interest me. >> >> Gene >> >> >> >> Hi Gene, >> >> >> You did not specify what the uses that interest you are, and >> I don't know about the use cases that interest Dan either, >> but I can speak for the use cases that interest me. >> >> >> EAP has been used in several cases as a magic way to use >> legacy credentials in protocols. I'll cite three examples: >> >> >> 1. L2TP/IPsec (RFC 3193) as implemented by Microsoft, Apple, >> Cisco and others, where an EAP method is used to authenticate >> the user. >> 2. IKEv2 (RFC 4306) where EAP is used to magically >> authenticate the initiator using non-cert and non-PSK credentials. >> 3. TEE (draft-nir-tls-eap-03) where EAP is used to >> authenticate the user. >> >> >> In all three cases EAP is used by a protocol inside an >> encrypted tunnel, where the server, which is either trusted >> by the authenticator or co-located with it is already >> authenticated by a certificate or PSK. IMO EAP was used in >> all cases an some magical way of making passwords into a >> secure authentication mechanism. The problem is that there >> really is no publicly available EAP method for passwords. >> >> >> Tunneled methods don't really make sense here. There's no >> benefit in putting a TLS tunnel inside an IKEv2 exchange just >> to pass the password. Something like EAP-SRP would be great >> if it (a) existed and (b) didn't have all that IPR baggage. >> The method that Dan is proposing would also be beneficial >> here, if we could get a WG behind it so we can get some solid >> security review. Instead, what implementors are doing is >> EAP-MD5 or EAP-GTC, which don't quite meet the requirements >> for any of the above protocols. >> >> >> Yoav >> >> >> >> >> >> >> > > Scanned by Check Point Total Security Gateway. > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
