While it is possible that one should require that network access services should require that channel binding be required. For the general purpose of this update we are restricted to updating for ABFAB usage cases and thus do not have the authority to put additional restrictions on the generic network access service case.
That being said, the original presentations in the EMU group did refer to the case of the lying NAS (either in terms of service ability or costs) as one of the things that needed to be addressed. This issue really needs to be addressed in EMU (or maybe EAP) in order to become any type of requirement. Jim From: [email protected] [mailto:[email protected]] On Behalf Of Alper Yegin Sent: Wednesday, July 25, 2012 8:57 AM To: Leif Johansson Cc: [email protected] Subject: Re: [abfab] EAP applicability statement comment 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
