Another comment: In most network access use cases all access servers that are served by a particular EAP server are providing the same or very similar types of service. The peer does not need to differentiate between different access network services supported by the same EAP server.
This is not accurate. In between the EAP peer and the EAP authentication server, there are zero or more independent service providers (access network provider, roaming exchange, roaming network provider). It's not like all of the access networks being served by the EAP auth server belong to the same service provider (that owns the EAP auth server too). The type of service the mobile device gets differ too (e.g., roaming vs non-roaming). Shouldn't the channel binding requirements equally apply to network access and non-network access cases? Alper On Jul 20, 2012, at 6:41 PM, Leif Johansson wrote: > > > > 20 jul 2012 kl. 16:24 skrev "Sam Hartman" <[email protected]>: > >> So, I'm really hoping that from a process standpoint we can not look to >> hard at this. I absolutely agree with Bernard that we need to implement >> things that meet the 4962 requirements. >> >> The implementation I have the most experience with (Moonshot) does >> implement RFC 4962. We use radsec as the key confidentiality method >> between AAA server and client. >> >> We basically require EAP-TTLS because that's all we're currently >> implementing channel binding for. >> >> The problem is that if we get too picky about IETF process, none of this >> works. In terms of standardized EAP methods with security, we have >> EAP-GPSK and EAP-TLS. >> EAP-TLS doesn't support channel binding and adding it would be >> difficult. >> EAP-GPSK probably is something we could use. However, it's the wrong fit >> for a lot of deployments. >> >> RADSEC is a good fit for what we want. Except it's not standards track. >> >> Long term, TEAP will be a standards-track method we can move to. >> Long term, either diameter will catch on, or we'll decide that RADSEC >> or some other form of security is appropriate for a normative reference >> from a standards-track spec. >> >> I don't think publishing ABFAB is experimental is the right approach. >> I don't think blocking ABFAB until EAP and RADEXT get done coming up >> with standards-track mechanisms is the right fix. >> >> So, I'm left concluding that being a bit liberal in our process and >> doing something reasonable with the implementations is the right >> approach here. >> >> So, I think that the right fix for the applicability statement is simply >> to refer to section 1.2 of RFC 4962 and note that is >> mandatory-to-implement. >> _______________________________________________ >> abfab mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/abfab > > > This approach sounds reasonable to me too. > > _______________________________________________ > abfab mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/abfab
_______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
